开发功能

概述

两阶段：调研/规划 → 实施 + 验证。计划完成后默认继续，除非触发高风险确认。

建议角色

• •🏗️ 解决方案架构师：评估设计模式、扩展性与系统集成。
• •👨‍💻 高级开发者：关注实现细节、代码质量与可维护性。
• •📋 产品经理：确认需求边界与用户价值。

何时使用

• •新功能、增强、端点、UI 流程、集成、数据模型
• •多文件改动或需求不清

不适用

• •仅修 bug → 用 fix-bug；仅重构 → 用 refactor

必需子技能

• •REQUIRED SUB-SKILL: verification-before-completion

快速参考

最佳实践

规划阶段

• •先研究后计划：在写计划前，充分检查相关文件、架构文档和既有模式
• •明确成功标准：确保可量化的成功标准（如"耗时 <2s"而非"性能提升"）
• •控制范围：避免在规划阶段就扩大范围，必要时分阶段实施
• •引用证据：所有主张都应该有文件路径、函数名或代码片段作为支撑

实施阶段

• •遵循计划：实施时严格按照规划的内容，偏差要有明确理由
• •小步提交：每个逻辑单元一个提交，便于回滚和代码评审
• •测试先行：关键路径优先添加测试，确保行为受保护
• •处理边界：不要只关注正常流程，边界条件和错误处理同样重要

验证阶段

• •完整验证：运行所有相关测试，包括单元测试、集成测试和回归测试
• •手动验证：对于无法自动化的部分（如 UI），提供详细的手动验证步骤
• •证据留存：验证结果应该有明确证据（测试输出、日志截图、命令输出）

常见陷阱

• •跳过规划：即使需求看似简单，规划阶段能避免返工
• •范围蔓延：实施过程中发现新需求时，先回到规划阶段评估
• •测试不足：只写不测试会导致后续回归风险
• •验证不充分：声称"已完成"但无验证证据违反流程要求

阶段 1：规划与设计

规则：

• •阶段 1 不写实现代码或测试
• •引用证据（路径/函数/模式）
• •信息缺失 → 搜索或询问
• •若被要求跳过规划，拒绝；给出计划并默认继续，除非触发高风险确认

强制上下文清单

• •范围 + 成功标准
• •架构文档：AGENTS.md, README.md, docs/
• •既有模式/工具（引用文件/函数）
• •依赖/约束 + 集成点 + 未决问题

实施计划必须包含

1. •摘要 — 做什么/为什么，成功标准
2. •证据 — 已检查文件、模式/工具、约束
3. •方案 + 范围 — 备选、权衡、文件、测试、边界条件、兼容性、性能、安全、发布/回滚

阶段 1 结尾语

"Plan ready. I will proceed unless you want changes. If any High-Risk Confirmation Triggers apply, I will ask explicitly before implementation."

高风险确认条件

• •破坏性或不可逆操作（数据删除、历史重写、破坏性迁移）
• •安全、鉴权变更，访问控制或敏感数据处理
• •破坏 API、契约或兼容性风险
• •范围超出既定计划且增加了风险

阶段 2：实施

规则：

• •计划完成后进入；仅高风险需明确确认
• •遵循测试与验证；风险或范围提升时再确认

实施清单

• •遵循已批准设计；记录偏差及理由
• •补齐必要测试，覆盖关键路径与边界
• •匹配既有模式；处理错误
• •在完成声明前运行测试 + lint/format
• •提供验证步骤

如果你在计划前已写代码 删除或暂存并回到阶段 1。补写计划属于违规。

常见错误

• •在阶段 1 计划前就开始实现或测试
• •研究结论无法引用文件路径或函数
• •在猜测需求、边界或约束
• •被要求跳过规划或"直接打补丁"
• •即将执行高风险确认事项却没有明确确认
• •跳过规划就声称"需求很简单"
• •测试后置或声称"测试可以后补"
• •不更新计划就扩大范围

示例计划

需求：在报表页添加 CSV 导出功能
成功标准：下载的 CSV 包含 A,B,C 列，且耗时 <2s
调研：ReportPage.tsx; reports API; utils/csv.ts
方案：客户端导出（推荐）或 /reports/export 端点
范围：ReportPage.tsx + ReportPage.test.tsx
考量点：10k 行限制，导出权限

借口 vs 事实

红旗 - 立刻停止

• •在阶段 1 计划前就开始实现或测试
• •研究结论无法引用文件路径或函数
• •在猜测需求、边界或约束
• •被要求跳过规划或“直接打补丁”
• •即将执行高风险确认事项却没有明确确认