长对话里，决定、改动和验证容易失联
在 AI 辅助编程中，讨论、决定、改动和验证容易混在一段长对话里。回头看时不容易知道哪些结论已经确认、对应改了什么，也找不到每一步的产物和验证结果。更大的风险是模糊请求一路进入实施，甚至碰到真实环境操作。
对一次性浏览的人来说，最终决定也很难从长聊天里抽出来；对实施者来说，没有明确验收点，就难以复跑结果或说明改动是否完成。
先明确入口和阶段边界，再允许流程往下走
我把它设计成一组有明确入口和阶段边界的 Skill：需要显式触发的流程只有在用户明确调用后才进入；需要先冻结计划的步骤不会自动跳到实施；真实环境测试单独设置授权门槛。每条流程都约定结束时要留下的文件和路径，让阶段之间可以交接。
这样，用户能分清当前是在梳理问题、确认方案、实施改动，还是核对真实环境，不会把一次普通讨论误当成执行许可。
不同流程也保留不同门槛：纯文字整理可以轻量完成，改变产品范围的方案要先确认，真实环境动作则单独核对授权与证据。
把验收标准、测试记录和提交连成追溯链
从需求澄清到 PRD（产品需求文档）、原型、任务拆分，再到 TDD（先运行失败测试，再实现并验证）和缺陷处理，我负责维护规则与产物契约。任务卡把验收标准对应到具体测试；实施记录 RED / GREEN、验证命令与提交，读者可按路径追溯决定、实现和结果。
决定与实现分别保留在文档和 Git 中；真实测试、线上操作或其他高影响步骤，按对应流程先满足授权边界。
技术细节
任务级规则要求每张可自动化任务卡标出准确的验收标准和测试位置；TDD 卡先运行测试确认功能缺失，再实现并运行到通过。无法自动化的检查要明确标记原因，不把代码审查写成实际运行结果。
缺陷流程与需求流程有不同触发和阶段规则。项目材料未提供可核实的节省时间、错误率或采用规模，因此不把流程存在本身当作量化收益。
用于日常开发，保留决定、产物和验证记录
这套体系用于日常开发，保留决策、产物和验证记录。作品集用两段完整预设对话展示“需求到原型”和“缺陷到验证”，每段都可手动打开关联文件；它们是预设材料，不是访客提问或在线执行。
两段对话会展示确认如何变成文档、任务与验证记录，但不会伪装成模型现场生成或项目现场运行。
目前能确认的是规则、产物路径与验证链可追溯，以及项目持续用于日常开发；没有测量时间节省或质量变化，所以不编造效率、错误率或用户规模。