plandex Plan Config 计划配置全解析从数据库设计、CLI 命令到自动化工作流的完整实现【免费下载链接】plandexOpen source AI coding agent. Designed for large projects and real world tasks.项目地址: https://gitcode.com/GitHub_Trending/pl/plandex本文以 plandex 仓库内功能设计文档 app/plans/plan-config.md 为主线结合其落地源码系统讲解 plandex 计划级配置Plan Config特性的设计初衷、数据模型、16 个配置项与 Auto Mode 预设、config/set-config命令体系、服务端 API 与数据库层实现以及它如何驱动tell/continue/build/chat等命令的自动化行为。读完你将完整掌握 plandex 中计划配置从数据库字段到命令行交互的全链路工作原理并能在实际项目里按需定制属于自己的自动化工作流。一、Plan Config 是什么一份设计蓝图到完整落地plandex是一款面向大型项目与真实世界任务的开源 AI 编程智能体。在其仓库的 app/plans/plan-config.md 中保存着一份完整的计划配置Plan Config功能设计文档。这份文档虽然以需求/设计说明的形式写成但它本身就是该功能的权威技术规格它精确到数据库字段、命令行为、服务端/客户端分工与配置项清单。根据设计文档Plan Config 功能需要满足以下核心诉求参照两个既有子系统建模松散地以计划模型设置plan model settings与模型包model packs功能为设计蓝本保证交互与心智模型的一致性纯数据库存储在plans表上新增一个plan_configJSON 字段保存配置不写入文件系统、不涉及 git配置只存在于数据库中独立的命令体系新增独立于models/set-model的配置查看与修改命令且拥有自己的源码文件双层级配置除计划级配置外还要有用户级默认配置Default Plan Config新的计划创建时自动继承用户默认配置类似set-model与set-model default的对应关系命令消费配置tell、continue、build、chat等执行命令默认读取配置作为默认行为同时保留既有 flags 的显式覆盖能力。值得注意的是设计文档最初把命令命名为settings与set最终落地实现命名为config与set-config并额外衍生出set-auto这正是设计蓝图 → 实现调整的典型体现下文会逐一对照。二、数据模型与存储JSON 字段如何落地2.1 数据库迁移设计文档要求服务端需要 api handlers、db handlers 和 db up/down 迁移。仓库中对应迁移文件为 2024121400_plan_config.up.sql 与 2024121400_plan_config.down.sql-- up ALTER TABLE plans ADD COLUMN IF NOT EXISTS plan_config JSON; ALTER TABLE users ADD COLUMN IF NOT EXISTS default_plan_config JSON; -- down ALTER TABLE plans DROP COLUMN IF EXISTS plan_config; ALTER TABLE users DROP COLUMN IF EXISTS default_plan_config;两张表、两个 JSON 列构成了双层级配置的存储底座plans.plan_config计划级配置随计划生命周期存在users.default_plan_config用户级默认配置作为新计划的配置模板。2.2 Go 端结构体与序列化配置的 Go 模型定义在 app/shared/plan_config.go 的PlanConfig结构体中第 53-97 行它实现了sql.Scanner与driver.Valuer接口第 101-126 行使得配置可以透明地以 JSON 形式读写数据库Scan时对nil/空值回退为DefaultPlanConfigValue()时通过json.Marshal序列化。这意味着即便某条计划的plan_config列为 NULL读取到的也是语义完整的默认配置对象。结构体中标注的字段含被注释掉的设计未采纳项清晰地展示了该特性的演进初始规划仅 6 个布尔/整型属性最终扩展为覆盖上下文、构建、应用、执行、调试、提交等全流程的配置体系。2.3 新计划创建时如何继承默认配置用户级默认配置在计划创建时被写入新计划这一逻辑位于 app/server/db/plan_helpers.go 的CreatePlan中第 23-44 行事务内先通过GetDefaultPlanConfig(userId)读取用户默认配置再连同org_id、project_id、name等一起 INSERT 进plans表。也就是说新建计划自动套用用户默认配置从第一行数据写入就已成立而不是等到首次运行时才解析。三、配置项体系从初始 6 个属性到 16 个配置项3.1 设计文档规划的初始属性设计文档明确要求初始包含以下属性AutoApply bool AutoCommit bool AutoContext bool NoExec bool AutoDebug bool AutoDebugTries int在最终实现中这些属性被一一映射为ConfigSettingsByKey注册表中的配置键见 app/shared/plan_config.go设计文档属性实现配置键展示名说明AutoApplyautoapplyauto-apply计划完成后自动应用变更AutoCommitautocommitauto-commit应用后自动提交 gitAutoContextautoloadcontextauto-load-context自动查找并加载上下文NoExeccanexeccan-exec是否允许执行命令取反关系AutoDebugautodebugauto-debug自动调试失败的命令AutoDebugTriesautodebugtriesauto-debug-tries自动调试尝试次数注意NoExec在实现中反向表达为CanExecCLI 执行命令时的--no-execflag 对应!config.CanExec。3.2 Auto Mode 预设一键切换自动化程度为了让 16 个布尔开关不被割裂使用实现引入AutoModeType预设体系第 21-46 行共 6 档full全自动——上下文、应用、执行、调试全部自动semi默认值自动上下文手动应用与执行plus手动上下文但带自动更新与智能加载手动应用与执行basic全手动上下文手动应用与执行none完全手动、逐步执行一次一个响应custom用set-config逐项自定义任何单项被修改后自动落入此档。SetAutoMode第 128-203 行一次性批量写入该档位对应的所有字段而init()第 491-498 行将DefaultPlanConfig初始化为AutoModeSemi同时把AutoModeChoices形如Semi Auto → Auto context, manual apply and execution与AutoModeLabels组装好供 CLI 交互选择使用。也就是说任何计划在没有任何显式配置时默认都是自动上下文 手动应用与执行的半自动模式。3.3 完整配置项速查表最终实现的全部配置键、展示名与含义如下注册于 ConfigSettingsByKey配置键展示名类型说明automodeauto-modestring预设自动化档位editoreditorstring首选编辑器autocontinueauto-continuebool持续迭代直到计划完成autobuildauto-buildbool自动生成待处理的文件编辑autoupdatecontextauto-update-contextbool变更后自动更新上下文autoloadcontextauto-load-contextbool自动查找并加载上下文smartcontextsmart-contextbool仅为计划中每个任务加载必要上下文autocommitauto-commitbool应用后自动提交 gitskipcommitskip-commitbool应用后跳过 git 提交autoapplyauto-applybool计划完成后自动应用变更canexeccan-execbool允许执行命令autoexecauto-execbool应用后自动执行命令autodebugauto-debugbool自动调试失败的命令autodebugtriesauto-debug-triesint自动调试尝试次数默认 5autorevertauto-revertbool回退计划时自动更新项目文件skipchangesmenuskip-changes-menubool跳过响应结束且有待处理变更时的交互菜单3.4 配置项之间的联动与约束从 BoolSetter/IntSetter 实现 可以清楚看到各开关并非相互独立而是存在强联动修改任一自动化开关都会把AutoMode置为custom前提是新值与旧值不同保证预设与手工定制不互相污染关闭autobuild会同时关闭autoapply开启autoapply会强制开启autobuildcanexec关闭会连带关闭autoexec与autodebugautoexec开启会强制开启canexec关闭则连带关闭autodebugautodebug开启会强制开启canexec与autoexec且当AutoDebugTries 0时自动回填默认值defaultAutoDebugTries 5第 10 行autodebugtries设为 0 时等价于关闭autodebugautoexec、autodebug、autodebugtries均声明了Visible条件分别要求CanExec、AutoExec、AutoDebug为真因此config命令的表格展示会随配置状态动态显隐避免展示无意义的开关。四、CLI 命令体系查看与修改配置4.1config与config default查看命令实现在 app/cli/cmd/config.goplandex config展示当前计划的配置。要求已解析认证与项目、存在当前计划否则输出No current plan错误通过api.Client.GetPlanConfig(lib.CurrentPlanId)拉取后用表格渲染见下plandex config default展示用户级默认配置即新计划会继承的模板。表格渲染由 app/cli/lib/plan_config.go 的ShowPlanConfig完成列头为Name / Value / Description按SortKeyautomode的 SortKey 为0保证排最前其余按配置键字母序排序并过滤掉不满足Visible条件的行同时可指定key只高亮展示单个配置项。命令执行完毕后还会通过term.PrintCmds给出下一步建议命令例如config default set-config set-config default4.2set-config与set-config default修改命令实现在 app/cli/cmd/set_config.go用法为plandex set-config [setting] [value] plandex set-config default [setting] [value]设计文档要求交互提示与用户输入方式沿用set-model的做法且不引入任何新依赖实现完全遵循了这一点——全部交互复用term包的SelectFromList、GetRequiredUserStringInput等既有组件带两个参数直接以命令行参数更新如plandex set-config auto-debug-tries 3、plandex set-config auto-apply enabled带一个参数指定配置键但省略值则按配置类型弹交互选择布尔型弹Enabled/Disabled整型提示输入数字枚举型弹选项列表不带参数弹出一个按Name → Desc格式排序列出的配置键选择列表选中后再按类型进入值输入环节编辑器类配置editor走lib.SelectEditor(false)的选择器直接传字符串值时会按空白切分为命令 参数。布尔值解析parseBooleanArg支持enabled/true/t/yes/y/1与disabled/false/f/no/n/0两组写法。更新成功后输出✅ Config updated随后以表格展示被修改项并根据变更结果给出针对性警告同时开启了自动应用与自动执行⚠️ You enabled automatic apply and execution.仅开启自动应用或自动执行时分别提示对应警告。更有趣的是配置变更的副作用loadMapIfNeeded与removeMapIfNeeded第 332-378 行会在开启auto-load-context时自动加载上下文映射若当前无 map在关闭时自动清理自动加载的 map保证配置与上下文状态即时一致。4.3set-auto快捷设定自动化档位实现中还额外提供了 set-auto 命令族含set-auto default本质是set-config auto-mode [value]的语法糖例如plandex set-auto full可一键切换到全自动模式。4.4 命令建议与帮助设计文档要求更新 CLI help 输出并为新命令添加建议。这体现在config/config default/set-config/set-config default四条命令在各自的init()中注册进RootCmdconfig.go 第 14-17 行、set_config.go 第 19-24 行且每条命令执行后都会通过term.PrintCmds输出关联建议命令形成完整的命令发现闭环。五、服务端实现API、DB 与路由5.1 路由注册设计文档明确要求服务端新建 API 与 DB handler 文件而不是塞进既有 plan settings handler。路由注册位于 app/server/routes/routes.goGET /plans/{planId}/config → handlers.GetPlanConfigHandler PUT /plans/{planId}/config → handlers.UpdatePlanConfigHandler GET /default_plan_config → handlers.GetDefaultPlanConfigHandler PUT /default_plan_config → handlers.UpdateDefaultPlanConfigHandler5.2 API Handler四个 handler 集中在独立的 app/server/handlers/plan_config.go两个计划级 handler 先经Authenticate认证、再经authorizePlan校验用户对计划的访问权限然后委托 DB 层读写plans.plan_config两个默认配置 handler 仅需认证Authenticate(w, r, true)以auth.User.Id作为用户维度主键更新类接口解码shared.UpdatePlanConfigRequest/shared.UpdateDefaultPlanConfigRequest请求/响应类型定义在 app/shared/req_res.go 中如GetPlanConfigResponse{Config}默认配置更新包在db.WithTx事务中执行。5.3 DB HelpersDB 层独立文件 app/server/db/plan_config_helpers.go 提供四个函数第 11-65 行GetPlanConfig(planId)SELECT plan_config FROM plans WHERE id $1StorePlanConfig(planId, config)UPDATE plans SET plan_config $1 WHERE id $2GetDefaultPlanConfig(userId)SELECT default_plan_config FROM users WHERE id $1StoreDefaultPlanConfig(userId, config, tx)带事务的UPDATE users ...。由于PlanConfig实现了driver.Valuer$1参数直接传入结构体即可自动 JSON 序列化无需手工编解码。5.4 CLI API 客户端客户端接口与实现在 app/cli/api/methods.goGetPlanConfig/UpdatePlanConfig/GetDefaultPlanConfig/UpdateDefaultPlanConfig四个方法统一走authenticatedFastClient并在遇到鉴权过期错误时通过refreshAuthIfNeeded刷新后自动重试。六、配置如何驱动命令执行默认值 flags 覆盖设计文档要求更新tell、continue、build、chat命令让它们默认使用配置设置可被既有 flags 覆盖。这一要求落地为 app/cli/cmd/plan_exec_helpers.go 中的mustSetPlanExecFlags第 158-219 行它在tell/continue/build等命令执行前被调用核心逻辑是config : lib.MustGetCurrentPlanConfig() if !cmd.Flags().Changed(stop) { tellStop !config.AutoContinue } if !cmd.Flags().Changed(no-build) { tellNoBuild !config.AutoBuild } if !cmd.Flags().Changed(auto-update-context) { autoConfirm config.AutoUpdateContext } if !cmd.Flags().Changed(apply) { tellAutoApply config.AutoApply } if !cmd.Flags().Changed(skip-commit) { skipCommit config.SkipCommit } if !cmd.Flags().Changed(commit) { autoCommit config.AutoCommit } if !cmd.Flags().Changed(auto-load-context) { tellAutoContext config.AutoLoadContext } if !cmd.Flags().Changed(smart-context) { tellSmartContext config.SmartContext } if !cmd.Flags().Changed(no-exec) { noExec !config.CanExec } if !cmd.Flags().Changed(auto-exec) { autoExec config.AutoExec } if !cmd.Flags().Changed(debug) { autoDebug config.AutoDebugTries } if !cmd.Flags().Changed(skip-menu) { tellSkipMenu config.SkipChangesMenu }可以提炼出的优先级规则是显式传入的 flag 永远优先只有 flag 未被设置时才回退到配置值。例如配置了auto-debug后直接运行plandex tell ...就会自动尝试调试失败命令最多auto-debug-tries次而--debug 0或--no-debug可以临时关闭。此外editor配置仅在值为vim/nano时被tell命令读取其余情况以 flag 或EDITOR环境变量为准。配置在 CLI 侧由 app/cli/lib/plan_config.go 的MustGetCurrentPlanConfig获取并做进程内缓存SetCachedPlanConfig可在set-config更新后刷新缓存。这些 flag 变量随后被apply.go、build.go、continue.go、chat.go等命令构造的TellPlanRequest/BuildPlanRequest使用如 app/cli/cmd/apply.go 的AutoApply: tellAutoApply, AutoDebug: autoDebug最终影响服务端执行流程的自动化程度。七、new命令创建计划即展示默认配置设计文档要求new命令在计划创建后以类似config命令的友好格式展示默认设置。实现在 app/cli/cmd/new.gonew通过两个 goroutine 并发执行创建计划与拉取默认配置api.Client.GetDefaultPlanConfig()两者都成功后输出✅ Started new plan name and set it to current plan ⚙️ Using default config随后resolveAutoMode(config)根据默认配置的AutoMode与AutoLoadContext等字段决定后续行为例如自动加载上下文映射并按配置展示对应的建议命令tell/chat/config或config/plans/cd/models。这使用户在新建计划的第一时间就能看到自己将默认以何种自动化程度工作。八、设计文档与落地实现对照总览设计文档要求app/plans/plan-config.md落地实现plans表新增plan_configJSON 字段2024121400_plan_config.up.sql用户级默认配置set defaultusers.default_plan_config列 config default/set-config defaultsettings/set新命令独立文件最终命名为 config.go 与 set_config.go另附set-auto初始 6 个属性映射为 16 个配置键 auto-mode预设见上文速查表服务端独立 API/DB handler 文件handlers/plan_config.go db/plan_config_helpers.go客户端 API 接口与实现app/cli/api/methods.gotell/continue/build/chat默认读配置、flags 可覆盖plan_exec_helpers.go 的mustSetPlanExecFlagsnew命令展示默认设置new.go不落文件系统、不用 git纯 DB 存储PlanConfig实现sql.Scanner/driver.Valuer仅与plans/users表交互至此从一份功能设计文档出发plandex 的 Plan Config 特性已经形成了数据库 JSON 字段 → 共享结构体与配置注册表 → CLI 查看/修改命令 → API 路由与 DB helpers → 执行命令默认值消费的完整闭环。理解这条链路后无论是为团队统一默认自动化策略set-config default还是为单个计划定制精细的调试/执行行为set-configset-auto你都可以做到心中有数、按需取用。【免费下载链接】plandexOpen source AI coding agent. Designed for large projects and real world tasks.项目地址: https://gitcode.com/GitHub_Trending/pl/plandex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
plandex Plan Config 计划配置全解析从数据库设计、CLI 命令到自动化工作流的完整实现【免费下载链接】plandexOpen source AI coding agent. Designed for large projects and real world tasks.项目地址: https://gitcode.com/GitHub_Trending/pl/plandex本文以 plandex 仓库内功能设计文档 app/plans/plan-config.md 为主线结合其落地源码系统讲解 plandex 计划级配置Plan Config特性的设计初衷、数据模型、16 个配置项与 Auto Mode 预设、config/set-config命令体系、服务端 API 与数据库层实现以及它如何驱动tell/continue/build/chat等命令的自动化行为。读完你将完整掌握 plandex 中计划配置从数据库字段到命令行交互的全链路工作原理并能在实际项目里按需定制属于自己的自动化工作流。一、Plan Config 是什么一份设计蓝图到完整落地plandex是一款面向大型项目与真实世界任务的开源 AI 编程智能体。在其仓库的 app/plans/plan-config.md 中保存着一份完整的计划配置Plan Config功能设计文档。这份文档虽然以需求/设计说明的形式写成但它本身就是该功能的权威技术规格它精确到数据库字段、命令行为、服务端/客户端分工与配置项清单。根据设计文档Plan Config 功能需要满足以下核心诉求参照两个既有子系统建模松散地以计划模型设置plan model settings与模型包model packs功能为设计蓝本保证交互与心智模型的一致性纯数据库存储在plans表上新增一个plan_configJSON 字段保存配置不写入文件系统、不涉及 git配置只存在于数据库中独立的命令体系新增独立于models/set-model的配置查看与修改命令且拥有自己的源码文件双层级配置除计划级配置外还要有用户级默认配置Default Plan Config新的计划创建时自动继承用户默认配置类似set-model与set-model default的对应关系命令消费配置tell、continue、build、chat等执行命令默认读取配置作为默认行为同时保留既有 flags 的显式覆盖能力。值得注意的是设计文档最初把命令命名为settings与set最终落地实现命名为config与set-config并额外衍生出set-auto这正是设计蓝图 → 实现调整的典型体现下文会逐一对照。二、数据模型与存储JSON 字段如何落地2.1 数据库迁移设计文档要求服务端需要 api handlers、db handlers 和 db up/down 迁移。仓库中对应迁移文件为 2024121400_plan_config.up.sql 与 2024121400_plan_config.down.sql-- up ALTER TABLE plans ADD COLUMN IF NOT EXISTS plan_config JSON; ALTER TABLE users ADD COLUMN IF NOT EXISTS default_plan_config JSON; -- down ALTER TABLE plans DROP COLUMN IF EXISTS plan_config; ALTER TABLE users DROP COLUMN IF EXISTS default_plan_config;两张表、两个 JSON 列构成了双层级配置的存储底座plans.plan_config计划级配置随计划生命周期存在users.default_plan_config用户级默认配置作为新计划的配置模板。2.2 Go 端结构体与序列化配置的 Go 模型定义在 app/shared/plan_config.go 的PlanConfig结构体中第 53-97 行它实现了sql.Scanner与driver.Valuer接口第 101-126 行使得配置可以透明地以 JSON 形式读写数据库Scan时对nil/空值回退为DefaultPlanConfigValue()时通过json.Marshal序列化。这意味着即便某条计划的plan_config列为 NULL读取到的也是语义完整的默认配置对象。结构体中标注的字段含被注释掉的设计未采纳项清晰地展示了该特性的演进初始规划仅 6 个布尔/整型属性最终扩展为覆盖上下文、构建、应用、执行、调试、提交等全流程的配置体系。2.3 新计划创建时如何继承默认配置用户级默认配置在计划创建时被写入新计划这一逻辑位于 app/server/db/plan_helpers.go 的CreatePlan中第 23-44 行事务内先通过GetDefaultPlanConfig(userId)读取用户默认配置再连同org_id、project_id、name等一起 INSERT 进plans表。也就是说新建计划自动套用用户默认配置从第一行数据写入就已成立而不是等到首次运行时才解析。三、配置项体系从初始 6 个属性到 16 个配置项3.1 设计文档规划的初始属性设计文档明确要求初始包含以下属性AutoApply bool AutoCommit bool AutoContext bool NoExec bool AutoDebug bool AutoDebugTries int在最终实现中这些属性被一一映射为ConfigSettingsByKey注册表中的配置键见 app/shared/plan_config.go设计文档属性实现配置键展示名说明AutoApplyautoapplyauto-apply计划完成后自动应用变更AutoCommitautocommitauto-commit应用后自动提交 gitAutoContextautoloadcontextauto-load-context自动查找并加载上下文NoExeccanexeccan-exec是否允许执行命令取反关系AutoDebugautodebugauto-debug自动调试失败的命令AutoDebugTriesautodebugtriesauto-debug-tries自动调试尝试次数注意NoExec在实现中反向表达为CanExecCLI 执行命令时的--no-execflag 对应!config.CanExec。3.2 Auto Mode 预设一键切换自动化程度为了让 16 个布尔开关不被割裂使用实现引入AutoModeType预设体系第 21-46 行共 6 档full全自动——上下文、应用、执行、调试全部自动semi默认值自动上下文手动应用与执行plus手动上下文但带自动更新与智能加载手动应用与执行basic全手动上下文手动应用与执行none完全手动、逐步执行一次一个响应custom用set-config逐项自定义任何单项被修改后自动落入此档。SetAutoMode第 128-203 行一次性批量写入该档位对应的所有字段而init()第 491-498 行将DefaultPlanConfig初始化为AutoModeSemi同时把AutoModeChoices形如Semi Auto → Auto context, manual apply and execution与AutoModeLabels组装好供 CLI 交互选择使用。也就是说任何计划在没有任何显式配置时默认都是自动上下文 手动应用与执行的半自动模式。3.3 完整配置项速查表最终实现的全部配置键、展示名与含义如下注册于 ConfigSettingsByKey配置键展示名类型说明automodeauto-modestring预设自动化档位editoreditorstring首选编辑器autocontinueauto-continuebool持续迭代直到计划完成autobuildauto-buildbool自动生成待处理的文件编辑autoupdatecontextauto-update-contextbool变更后自动更新上下文autoloadcontextauto-load-contextbool自动查找并加载上下文smartcontextsmart-contextbool仅为计划中每个任务加载必要上下文autocommitauto-commitbool应用后自动提交 gitskipcommitskip-commitbool应用后跳过 git 提交autoapplyauto-applybool计划完成后自动应用变更canexeccan-execbool允许执行命令autoexecauto-execbool应用后自动执行命令autodebugauto-debugbool自动调试失败的命令autodebugtriesauto-debug-triesint自动调试尝试次数默认 5autorevertauto-revertbool回退计划时自动更新项目文件skipchangesmenuskip-changes-menubool跳过响应结束且有待处理变更时的交互菜单3.4 配置项之间的联动与约束从 BoolSetter/IntSetter 实现 可以清楚看到各开关并非相互独立而是存在强联动修改任一自动化开关都会把AutoMode置为custom前提是新值与旧值不同保证预设与手工定制不互相污染关闭autobuild会同时关闭autoapply开启autoapply会强制开启autobuildcanexec关闭会连带关闭autoexec与autodebugautoexec开启会强制开启canexec关闭则连带关闭autodebugautodebug开启会强制开启canexec与autoexec且当AutoDebugTries 0时自动回填默认值defaultAutoDebugTries 5第 10 行autodebugtries设为 0 时等价于关闭autodebugautoexec、autodebug、autodebugtries均声明了Visible条件分别要求CanExec、AutoExec、AutoDebug为真因此config命令的表格展示会随配置状态动态显隐避免展示无意义的开关。四、CLI 命令体系查看与修改配置4.1config与config default查看命令实现在 app/cli/cmd/config.goplandex config展示当前计划的配置。要求已解析认证与项目、存在当前计划否则输出No current plan错误通过api.Client.GetPlanConfig(lib.CurrentPlanId)拉取后用表格渲染见下plandex config default展示用户级默认配置即新计划会继承的模板。表格渲染由 app/cli/lib/plan_config.go 的ShowPlanConfig完成列头为Name / Value / Description按SortKeyautomode的 SortKey 为0保证排最前其余按配置键字母序排序并过滤掉不满足Visible条件的行同时可指定key只高亮展示单个配置项。命令执行完毕后还会通过term.PrintCmds给出下一步建议命令例如config default set-config set-config default4.2set-config与set-config default修改命令实现在 app/cli/cmd/set_config.go用法为plandex set-config [setting] [value] plandex set-config default [setting] [value]设计文档要求交互提示与用户输入方式沿用set-model的做法且不引入任何新依赖实现完全遵循了这一点——全部交互复用term包的SelectFromList、GetRequiredUserStringInput等既有组件带两个参数直接以命令行参数更新如plandex set-config auto-debug-tries 3、plandex set-config auto-apply enabled带一个参数指定配置键但省略值则按配置类型弹交互选择布尔型弹Enabled/Disabled整型提示输入数字枚举型弹选项列表不带参数弹出一个按Name → Desc格式排序列出的配置键选择列表选中后再按类型进入值输入环节编辑器类配置editor走lib.SelectEditor(false)的选择器直接传字符串值时会按空白切分为命令 参数。布尔值解析parseBooleanArg支持enabled/true/t/yes/y/1与disabled/false/f/no/n/0两组写法。更新成功后输出✅ Config updated随后以表格展示被修改项并根据变更结果给出针对性警告同时开启了自动应用与自动执行⚠️ You enabled automatic apply and execution.仅开启自动应用或自动执行时分别提示对应警告。更有趣的是配置变更的副作用loadMapIfNeeded与removeMapIfNeeded第 332-378 行会在开启auto-load-context时自动加载上下文映射若当前无 map在关闭时自动清理自动加载的 map保证配置与上下文状态即时一致。4.3set-auto快捷设定自动化档位实现中还额外提供了 set-auto 命令族含set-auto default本质是set-config auto-mode [value]的语法糖例如plandex set-auto full可一键切换到全自动模式。4.4 命令建议与帮助设计文档要求更新 CLI help 输出并为新命令添加建议。这体现在config/config default/set-config/set-config default四条命令在各自的init()中注册进RootCmdconfig.go 第 14-17 行、set_config.go 第 19-24 行且每条命令执行后都会通过term.PrintCmds输出关联建议命令形成完整的命令发现闭环。五、服务端实现API、DB 与路由5.1 路由注册设计文档明确要求服务端新建 API 与 DB handler 文件而不是塞进既有 plan settings handler。路由注册位于 app/server/routes/routes.goGET /plans/{planId}/config → handlers.GetPlanConfigHandler PUT /plans/{planId}/config → handlers.UpdatePlanConfigHandler GET /default_plan_config → handlers.GetDefaultPlanConfigHandler PUT /default_plan_config → handlers.UpdateDefaultPlanConfigHandler5.2 API Handler四个 handler 集中在独立的 app/server/handlers/plan_config.go两个计划级 handler 先经Authenticate认证、再经authorizePlan校验用户对计划的访问权限然后委托 DB 层读写plans.plan_config两个默认配置 handler 仅需认证Authenticate(w, r, true)以auth.User.Id作为用户维度主键更新类接口解码shared.UpdatePlanConfigRequest/shared.UpdateDefaultPlanConfigRequest请求/响应类型定义在 app/shared/req_res.go 中如GetPlanConfigResponse{Config}默认配置更新包在db.WithTx事务中执行。5.3 DB HelpersDB 层独立文件 app/server/db/plan_config_helpers.go 提供四个函数第 11-65 行GetPlanConfig(planId)SELECT plan_config FROM plans WHERE id $1StorePlanConfig(planId, config)UPDATE plans SET plan_config $1 WHERE id $2GetDefaultPlanConfig(userId)SELECT default_plan_config FROM users WHERE id $1StoreDefaultPlanConfig(userId, config, tx)带事务的UPDATE users ...。由于PlanConfig实现了driver.Valuer$1参数直接传入结构体即可自动 JSON 序列化无需手工编解码。5.4 CLI API 客户端客户端接口与实现在 app/cli/api/methods.goGetPlanConfig/UpdatePlanConfig/GetDefaultPlanConfig/UpdateDefaultPlanConfig四个方法统一走authenticatedFastClient并在遇到鉴权过期错误时通过refreshAuthIfNeeded刷新后自动重试。六、配置如何驱动命令执行默认值 flags 覆盖设计文档要求更新tell、continue、build、chat命令让它们默认使用配置设置可被既有 flags 覆盖。这一要求落地为 app/cli/cmd/plan_exec_helpers.go 中的mustSetPlanExecFlags第 158-219 行它在tell/continue/build等命令执行前被调用核心逻辑是config : lib.MustGetCurrentPlanConfig() if !cmd.Flags().Changed(stop) { tellStop !config.AutoContinue } if !cmd.Flags().Changed(no-build) { tellNoBuild !config.AutoBuild } if !cmd.Flags().Changed(auto-update-context) { autoConfirm config.AutoUpdateContext } if !cmd.Flags().Changed(apply) { tellAutoApply config.AutoApply } if !cmd.Flags().Changed(skip-commit) { skipCommit config.SkipCommit } if !cmd.Flags().Changed(commit) { autoCommit config.AutoCommit } if !cmd.Flags().Changed(auto-load-context) { tellAutoContext config.AutoLoadContext } if !cmd.Flags().Changed(smart-context) { tellSmartContext config.SmartContext } if !cmd.Flags().Changed(no-exec) { noExec !config.CanExec } if !cmd.Flags().Changed(auto-exec) { autoExec config.AutoExec } if !cmd.Flags().Changed(debug) { autoDebug config.AutoDebugTries } if !cmd.Flags().Changed(skip-menu) { tellSkipMenu config.SkipChangesMenu }可以提炼出的优先级规则是显式传入的 flag 永远优先只有 flag 未被设置时才回退到配置值。例如配置了auto-debug后直接运行plandex tell ...就会自动尝试调试失败命令最多auto-debug-tries次而--debug 0或--no-debug可以临时关闭。此外editor配置仅在值为vim/nano时被tell命令读取其余情况以 flag 或EDITOR环境变量为准。配置在 CLI 侧由 app/cli/lib/plan_config.go 的MustGetCurrentPlanConfig获取并做进程内缓存SetCachedPlanConfig可在set-config更新后刷新缓存。这些 flag 变量随后被apply.go、build.go、continue.go、chat.go等命令构造的TellPlanRequest/BuildPlanRequest使用如 app/cli/cmd/apply.go 的AutoApply: tellAutoApply, AutoDebug: autoDebug最终影响服务端执行流程的自动化程度。七、new命令创建计划即展示默认配置设计文档要求new命令在计划创建后以类似config命令的友好格式展示默认设置。实现在 app/cli/cmd/new.gonew通过两个 goroutine 并发执行创建计划与拉取默认配置api.Client.GetDefaultPlanConfig()两者都成功后输出✅ Started new plan name and set it to current plan ⚙️ Using default config随后resolveAutoMode(config)根据默认配置的AutoMode与AutoLoadContext等字段决定后续行为例如自动加载上下文映射并按配置展示对应的建议命令tell/chat/config或config/plans/cd/models。这使用户在新建计划的第一时间就能看到自己将默认以何种自动化程度工作。八、设计文档与落地实现对照总览设计文档要求app/plans/plan-config.md落地实现plans表新增plan_configJSON 字段2024121400_plan_config.up.sql用户级默认配置set defaultusers.default_plan_config列 config default/set-config defaultsettings/set新命令独立文件最终命名为 config.go 与 set_config.go另附set-auto初始 6 个属性映射为 16 个配置键 auto-mode预设见上文速查表服务端独立 API/DB handler 文件handlers/plan_config.go db/plan_config_helpers.go客户端 API 接口与实现app/cli/api/methods.gotell/continue/build/chat默认读配置、flags 可覆盖plan_exec_helpers.go 的mustSetPlanExecFlagsnew命令展示默认设置new.go不落文件系统、不用 git纯 DB 存储PlanConfig实现sql.Scanner/driver.Valuer仅与plans/users表交互至此从一份功能设计文档出发plandex 的 Plan Config 特性已经形成了数据库 JSON 字段 → 共享结构体与配置注册表 → CLI 查看/修改命令 → API 路由与 DB helpers → 执行命令默认值消费的完整闭环。理解这条链路后无论是为团队统一默认自动化策略set-config default还是为单个计划定制精细的调试/执行行为set-configset-auto你都可以做到心中有数、按需取用。【免费下载链接】plandexOpen source AI coding agent. Designed for large projects and real world tasks.项目地址: https://gitcode.com/GitHub_Trending/pl/plandex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
