受控编码工作流

它解决的问题

AI 直接改项目代码时，容易把一次小修复扩散成跨模块改动，也可能在根因未确认时补兼容、加抽象、改 git 历史，最后留下难以回溯的变更。受控编码工作流 不追求让代码“更工程化”，而是把 修改范围、决策权限、验证方式和汇报责任 固定下来。只要涉及项目代码修改，都可以把它当作 Agent 的操作约束：先判断改动级别，再决定能否直接编辑。

核心工作方式

• 修改分级：极小修改 只处理语法修复、明显局部 bug、简单重命名等机械操作；简单修改 涉及轻微行为、数据流或测试调整；复杂修改 需要多模块或多段代码；架构级修改 会触及模块边界、依赖方向、公共接口、持久化或构建部署。
• 权限门槛：用户未授权自主推进时，简单修改 及以上先汇报系统状态、可选方案和执行路径；复杂修改 先给自然语言伪代码；架构级修改 先确认架构方案，再确认伪代码。用户明确授权离线推进时，可在结束时补汇报。
• 编辑原则：优先沿用项目现有结构、命名和依赖方向；不硬编码业务文案；不添加推测性的 fallback、兼容或新依赖；重构默认保持外部行为不变。
• 验证与调试：修改要形成前后测试链路，确认修改前问题可复现、修改后不再出现；根因不确定时先输出证据和未知点，不做猜测补丁；优先通过调试缩小范围，而不是反复试错。
• git 策略：对已绑定远程仓库的项目，除非用户明确要求，不 commit、push、merge、rebase、amend 或改写历史；仅本地记录时，结束自动 git add / git commit；用户要求提交时先对齐项目提交风格，默认使用 feat:、fix:、doc: 等前缀。
• 编辑后汇报：说明改动文件、实际差异、范围一致性、临时文件、验证结果、真实风险和后续动作。需要更细规则时读取 references/workflow-rules.md，需要声明、扩范围、决策、根因不明或编辑后报告措辞时读取 references/reporting-template.md。

适用边界与注意点

它适合需要把 AI 编码 Agent 纳入可审计流程的项目，不适合替代测试、CI、代码评审和架构决策。即使开启该工作流，Agent 仍可能面对信息不全、领域约束不明确或外部依赖异常；此时应停止并请求许可，而不是自行扩张边界。

发布与接入

资料标注为 Pay Skill，按 SkillHub 的 X402 微信 Agent Pay 改造；服务端生成微信支付订单，用开发者私钥做 SHA256withRSA 签名，换取 payment_code，以 HTTP 402 和 WeixinPay-Required 头要求 Agent 完成微信支付授权，支付证明回传后再返回业务结果。完整接入和本地联调见 x402/README.md。