十条 AI 编程命令实测暴露流程歧义

10 条 AI 编程命令写完，离能交付还有多远？作者整理了一轮真实调用记录：3 条无需修改，7 条各补了一处执行时需要猜测的规则。问题集中在测试放哪、基线失败怎么办、目标分支怎么选这些流程细节。

这份记录值得读的地方，是把「提示词看起来完整」和「工作流真的能执行」分开验证。但它只是一次小范围实测，能说明发现了哪些漏洞，还不足以证明整套命令已经稳定可靠。

命令能不能用，要放进真实任务里看

原文整理自完整版 2026-10-01 的测试记录 D1，并非新一轮实测。作者把 10 个中文 slash command（斜杠命令）分别实际调用一次，场景覆盖测试床和本仓库真实 git 历史。

测试床是 /tmp/cmdtest/orders.py，刻意埋了 3 个 bug：文件未关闭、访问 o["level"] 时发生 KeyError、浮点结果未舍入。测试环境为 pytest 9.1.1。

其中 3 条零修改通过：

• /plan 针对 CSV 导出、日期过滤，输出 5 个任务，附验收标准、依赖和涉及文件，还有 3 个 [待确认]、风险与并行顺序。
• /review 找出全部 3 个预埋 bug，正确区分 [必须改]、[建议改]、[可忽略]，每条都有原因和修改代码片段。
• /onboard 给出项目定位、地图、load→settle→summarize 关键路径及实际跑通的上手命令，第一处建议修改的位置准确落在 orders.py:26。

它们的共同点，是输入、输出格式、判定标准都足够具体。模型不必临时决定「接下来按什么规矩办」。

最容易漏掉的，是正常流程之外怎么办

另外 7 条命令各补了一处规则，基本都卡在流程分支。

/debug 复现了 batch_settle 接收缺失 level 的订单时发生的 KeyError，H1 第一个假设就确认了根因。但原流程没说剩余假设是否还要验证，于是出现了为完成步骤而继续验证的情况。补上的规则是：根因已经确认，剩余假设可标 [跳过]，并说明理由。

/test 为 calc_discount 列出 6 个用例，写入 test_orders.py，执行结果为 6 passed。问题是文件位置靠猜。补充约定后，有 tests/ 就放进去，否则与被测文件同目录，命名为 test_xxx.py。

/refactor 先约定返回值、打印内容不变，补上安全网并得到 2 passed，再把 summarize 拆成 calc_total + print_summary，最终得到 8 passed，最后完成收尾三问。这次基线恰好全绿，却暴露出另一种情况没有规定：如果动手前测试已经失败，应该怎么办？修订要求先报告失败，不带着红灯开始重构。

流程不仅要写成功时怎么走，还要写何时跳过、何时停下。

文档、提交和发版，也需要明确判定标准

/doc 支持注释、README、API 三类任务，但只细化了前两类。补上的 API 分支要求包含方法、路径、参数表、返回示例和错误码表。

这次实际执行的是注释任务：作者没有编造 calc_discount 折扣率的业务依据，而是标记 [待确认]；同时补充了 batch_settle 缺失 level 时默认 normal 的约定，修改后为 8 passed。这不能直接证明新增 API 分支已经验证通过。

/commit 面对 11 个已暂存的新文件，识别出 feat（10 commands）与 docs（选型）混在一起并提醒拆分。最终判断选型文档服务于同一目的，合并提交。修订补上了「是否为同一目的服务」的标准和正反例，避免只凭文件类型决定是否拆分。

/pr 在 d1-tuning 分支上，相对 master 的 5 个调优改动生成了完整描述，包含一句话、背景、改动点、怎么测、风险和自检。但目标分支原本靠猜，因此补上先确认默认分支 master/main，不确定就问用户。

/release 的 dry-run（试运行）发现，grep 搜到的 TODO 都是文档里的说明，并非代码里的裸 TODO。敏感信息检查通过；纯文档仓库的测试如实标为 N/A。由于 README 尚未完成，计划到 D5 才写，流程正确叫停发版。修订进一步明确：文档中解释 TODO 的文字不算检查失败。

我的判断

作者抓住了一个实用问题：提示词里的「相关改动」「确认根因」「检查通过」，如果没有可操作的标准，执行者仍然要替流程补设计。把这些判断写出来，有助于减少重复沟通。

但「3 条零修改、7 条各修 1 处」只描述这次样本。测试床规模有限，而且 /review 面对的是预先知道答案的 3 个 bug，不能据此推断它在复杂项目里的缺陷发现率。原文也没给出修订后的完整复测结果，更没有与普通提示词、人工流程的对照数据。

测试床最后保留了 2 个未修复 bug，即文件未关闭、浮点未舍入，以及 1 个已知约定，供后续复测使用。保留已知问题有利于检查命令是否退步，但还需要更多任务检验适用范围。

原文附带工作流包销售：早鸟 ¥9.90，限前 100 份，正式 ¥19.90。这轮记录能作为交付前的检查案例，不能单独充当成熟度证明。

能拿来做什么

• 给团队现有 AI 编程命令安排一次真实调用，记录执行中需要临时决定的事项，优先补齐文件位置、完成标准和失败处理规则。
• 在前端或 Node 项目的重构命令中明确测试基线要求；如果已有失败，先报告，避免把历史问题和本次改动混在一起。
• 给 PR、提交和发版命令补齐仓库约定，包括默认分支、同一目的的判断标准，以及检查结果何时应标为 N/A。
• 按改动范围选择复测范围。原文建议，仅改一处文案且未改变工作流步骤时，只跑受影响的命令；命令尚未写完、只是查看 Lite 版 3 条命令时，也不必照搬全量实测。