使用 Claude Code 的 /plan-feature 命令为 Archon 生成可执行实施计划：基于 WISC 框架的规范驱动开发实战

使用 Claude Code 的 /plan-feature 命令为 Archon 生成可执行实施计划基于 WISC 框架的规范驱动开发实战【免费下载链接】context-engineering-introContext engineering is the new vibe coding - its the way to actually make AI coding assistants work. Claude Code is the best for this so thats what this repo is centered around, but you can apply this strategy with any AI coding assistant!项目地址: https://gitcode.com/gh_mirrors/co/context-engineering-intro本篇指南深入解析use-cases/ai-coding-wisc-framework使用案例中的/plan-featureslash command 定义文件plan-feature.md说明如何让 Claude Code 通过并行子代理完成代码库侦察、产出结构化的功能实施计划并交由/execute命令在全新会话中按计划落地。读完本文你将掌握五阶段计划生成流水线、可复用的计划 Markdown 模板、任务排序与禁止模式清单以及如何将这份计划文件与 WISC 框架的 Write/Isolate/Select/Compress 四策略对齐。1. 命令定位plan-feature 在 WISC 框架中的角色WISC 是仓库use-cases/ai-coding-wisc-framework所演示的一套面向 AI 编码会话的上下文工程框架四个字母分别代表W - Write把 Agent 的记忆外化到文件使其在上下文重置后依然存活I - Isolate用子代理把研究噪音隔离在主会话之外S - Select只加载当前任务所需的上下文而非全部C - Compress会话过长时聚焦压缩或交接给新会话。框架的取舍顺序是刻意的——Write 与 Isolate 收益最大Select 是放大器Compress 是安全网。/plan-feature正是 Write 与 Isolate 两大策略的直接落地它把实现方案写进磁盘文件Write并靠并行研究子代理隔离代码库探索噪音Isolate。框架中规划与执行这一组命令的完整定位见 README.md 的 Planning Execution (Write) 小节。命令本体是标准的 Claude Code slash command 文件头部 frontmatter 声明了命令的意图与调用方式--- description: Create a comprehensive implementation plan for an Archon feature argument-hint: feature-name-or-description ---其中argument-hint提示你应当以功能名或功能描述作为参数调用例如/plan-feature 添加对 Discord 平台适配器的支持。命令随后产出并保存计划到.claude/archon/plans/{kebab-case-name}.md该文件专为同框架下的/execute命令见 execute.md设计——执行者只读计划、不带任何规划对话的包袱。2. Phase 1功能理解——先定义问题再谈实现命令要求 Claude Code 在动手研究代码之前先用一段话重述功能请求并识别五个维度Problem being solved——该功能解决什么用户痛点或能力缺口Success criteria——完成长什么样如何验证它真的工作Scope boundaries——明确哪些在范围内、哪些明确排除Package impact——涉及 8 个包中的哪些这 8 个包为paths、git、isolation、workflows、core、adapters、server、webInterface changes——是否触碰IPlatformAdapter、IAssistantClient、IDatabase或IWorkflowStore是否需要新接口这一阶段的产出是计划的契约底座。后续所有研究、任务拆分与验证步骤都以这里的成功标准为准绳避免实现过程偏离初衷。这也与仓库中另一套工作流 create-plan.md 的第 1 步读取并分析需求思路一致先把需求中的目标、约束、集成点、成功标准抽出来再谈设计。3. Phase 2代码库情报——四个并行子代理的侦察分工本阶段的核心是 Isolate 策略不要在主会话里读文件而是派生子代理去并行研究让探索噪音留在子会话内。命令定义了四个职责不同的子代理子代理任务参考命令A — 受影响包深潜阅读受影响包的全部相关源码绘制当前数据流识别每一个需要改动的文件无固定命令读packages/{pkg}/src/B — 接口与类型契约阅读packages/core/src/types/及各处index.ts导出弄清接口定义及其跨包消费方式无固定命令C — 测试模式找出与改动区域相似的既有测试阅读 2–3 个代表性测试文件理解 mock 模式、断言风格与各包的mock.module()隔离要求find packages/ -name *.test.ts \| head -30D — 相关历史工作阅读触碰相关文件的近期提交理解既有变更模式git log --oneline --all \| head -20四个子代理完成后命令要求综合产出当前状态、缺口、约束三要素作为后续战略思考的输入。子代理 C 关注的mock.module()隔离问题在仓库中有非常具体的依据use-cases/ai-coding-wisc-framework/.claude/rules-example/testing.md明确警告Bun 的mock.module()是进程级、永久性的模块替换mock.restore()无法撤销因此测试文件的分批与隔离直接决定测试的成败——这解释了为什么命令要求子代理 C 必须弄清每个包的mock.module()隔离要求。4. Phase 3外部研究按需——只在必要时联网如果功能涉及外部 API、新引入的库或陌生模式命令允许使用 web search 调研相关 SDK 的官方文档已知的坑或版本不兼容问题问题域内的社区实践模式。任何会影响实现路线的发现都必须被记录下来。注意这是一个按需阶段——不是每个计划都需要联网代码库内部已有答案的问题不应浪费外部研究预算。5. Phase 4战略思考——动笔写任务前的五个推演5.1 架构决策职责归属应用 SRP让每个模块只聚焦单一关注点包的新增还是扩展是新建一个包还是在既有包上扩展依赖方向绝不产生循环依赖。依赖链方向为paths ← git ← isolation/workflows ← core ← adapters ← server即paths在最底层零archon/*依赖server在最上层。这一依赖方向在 execute.md 的 Package boundaries 一节有可执行的落地版archon/workflows不得 importarchon/corearchon/git不得 importarchon/core或archon/workflows。5.2 接口设计优先扩展既有窄接口而不是制造胖接口新接口方法只在有具体的当前调用者时才添加除非确有必要避免给IPlatformAdapter或IAssistantClient增加方法。5.3 测试隔离策略牢记mock.module()是进程级且永久的Bun 环境规划测试文件放置位置要格外小心若为带分批测试的包core、workflows、adapters、isolation新增测试需确定新测试属于哪一批。仓库中testing.md记录了各包的分批情况例如archon/core分为 7 批、archon/workflows分为 5 批、archon/adapters分为 3 批、archon/isolation分为 3 批。5.4 ESLint 合规所有新函数必须显式声明返回类型不允许无理由的anyCI 强制零警告策略。5.5 回滚计划如果出错爆炸半径有多大改动能否在不做数据库迁移的情况下回退这一先想清楚再动手的节奏本质上就是 README.md 所强调的Write把决策写进计划文件让后续执行会话无需重新推导这些取舍。6. Phase 5计划生成——可直接消费的 Markdown 模板6.1 计划文件结构命令在.claude/archon/plans/{kebab-case-feature-name}.md生成计划完整模板如下# Plan: {Feature Name} ## Overview {1-2 sentence summary of what this implements and why.} ## Success Criteria - [ ] {Verifiable criterion 1} - [ ] {Verifiable criterion 2} - [ ] Passes bun run validate (type-check lint format tests) ## Affected Packages - archon/{package} — {what changes} ## Architecture Notes {Key decisions, tradeoffs, interface changes.} ## Implementation Tasks ### Task 1: {descriptive name} **File:** packages/{package}/src/{file}.ts **Type:** Create | Modify | Delete **Description:** {What this task does and why.} **Depends on:** {Task N, or none} ### Task 2: ... ## Validation Steps 1. bun run type-check — must pass with zero errors 2. bun run lint — must pass with zero warnings 3. bun run format:check — must pass 4. bun run test — must pass (run via bun --filter * test for isolation) 5. Manual test: {specific curl command or UI steps to verify the feature} ## Rollback Notes {How to safely revert if needed.}模板中的每个任务都带File、TypeCreate/Modify/Delete、Description、Depends on四个字段——这正是 execute.md 第 3 步按依赖顺序执行任务所依赖的机器可读结构。执行会话会逐个读取任务、先读目标文件再改、每改一个 TypeScript 文件就跑bun run type-check 21 | tail -20即时修复类型错误。6.2 任务排序规则按依赖排序被阻塞的任务必须排在其依赖之后尽量按包分组减少上下文切换数据库 schema 变更如有排最前类型/接口定义先于实现测试排在实现之后前端排在后端 API 稳定之后。6.3 禁止模式计划中见到即标记为风险import * as core from archon/core——必须使用具名导入无理由注释的any类型循环包依赖任何脚本或测试中出现git clean -fd从仓库根目录直接跑bun test应使用bun run test或bun --filter * test。最后一条有实测依据testing.md明确记录从仓库根目录运行bun test会引发约 135 个 mock 污染失败因此必须经由bun --filter * test实现每包隔离。这正是计划模板中 Validation Steps 第 4 步特意注明bun --filter * test的原因。同样地git clean -fd在 execute 命令中被替换为更安全的git checkout .。7. 输出与收尾计划的三重交付命令的最后一步要求将计划文件保存到.claude/archon/plans/{kebab-case-name}.md将计划打印到对话中汇总任务数量、受影响的包、预估复杂度低/中/高以及任何需要在执行前解决的风险或开放问题。这三重交付让人类可以审阅计划、提出修改再决定是否把它交给/execute。执行侧在 execute.md 中与之严格对称先通读全计划再核对git status与当前分支按依赖顺序实现每个任务每包增量跑type-check lint format:check test最后跑完整bun run validate并输出结构化执行报告完成任务、新建/修改文件、各项验证 PASS/FAIL、手工验证步骤、偏差记录。8. 实战要点把 plan-feature 融入你的 AI 编码工作流结合 README.md 的落地建议与命令本身的约束以下是可直接套用的要点先 Write/plan-feature生成的计划文件是规范即文档它把一次性的规划对话固化为可复现、可评审、可交给新会话的资产善用 Isolate让四个研究子代理并行侦察主会话只接收综合结论避免 30K token 的代码库探索噪音让 Select 决定计划内容每个任务只引用File字段列出的目标文件执行会话按计划精确加载上下文而非重新探索全库把 Compress 留到最后计划与/handoff、/commit等命令配合长任务的进度与决策都能外化到文件随时可在新会话续接。如果你希望把这一套计划先行、规范驱动的流程推广到非 Archon 项目仓库中的 ai-coding-workflows-foundation 提供了更通用的三阶段变体/primer探索 →/create-plan生成计划 →/execute-plan执行其计划模板同样强调 Overview、Research Findings、Implementation Tasks、Success Criteria 等要素可作为轻量替代或参考。【免费下载链接】context-engineering-introContext engineering is the new vibe coding - its the way to actually make AI coding assistants work. Claude Code is the best for this so thats what this repo is centered around, but you can apply this strategy with any AI coding assistant!项目地址: https://gitcode.com/gh_mirrors/co/context-engineering-intro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考