产品说给 DeepDesk 加一个问题分类标签。你把这句话丢给 AI它很可能直接给你生成一整套代码——标签管理、AI 推荐、统计报表、筛选条件、权限改造、数据库迁移。看起来勤奋但方向已经错了。问题不是 AI 不会写代码而是你缺少一条可控的操作流程。今天这篇文章我直接用真实命令演示AI 编程应该怎么一步步操作。你现在的工作流人肉流水线你现在的操作方式大概率是这样的你输入需求AI 追问澄清你确认你让 AI 创建提案你让 AI 拆任务你复制提示词到新窗口你让 AI 做 TDD你让 AI 做 review你人工判断是否可信。你在每个 AI 窗口之间当调度员复制提示词、切窗口、判断输出能不能用。更关键的问题是——写代码的和验收代码的是同一个 AI它不会主动告诉你哪里跳步了、哪里假设了。这就是提示词驱动的天花板。升级后的工作流一条命令启动闭环升级后你只需要输入一条命令使用 ai-loop基于 grill-with-docs 澄清 给 DeepDesk 增加一个问题分类标签功能。 不要直接写代码。一条命令启动整条闭环。总控 skill 是一个 SKILL.md 文件它管理状态机clarify → proposal → slice → ready → make → check → done → final-qa每个阶段调用对应的开源 skillgrill-with-docs 负责澄清OpenSpec 负责提案to-issues 负责切片writing-plans 和 TDD 负责执行review 负责验收qa 负责最终验收。你从流程调度员变成了关键决策者。 你只在四个节点说话提案确认、切片确认、BLOCKED 决策、最终验收。下面逐步看每一步的真实操作。第一步澄清阶段AI 不写代码你输入使用 ai-loop从 clarify 开始不要修改代码。 需求给 DeepDesk 增加一个问题分类标签功能。AI 先输出预检ai_loop_preflight:stateclarifycan_advancefalserequired_gateclarification然后开始追问。注意AI 不写代码不创建提案只问一个最关键的问题问题1这个问题分类标签是用户手动打标 还是 AI 自动推荐标签 推荐先做手动打标因为 AI 推荐需要训练数据 当前阶段没有。你回答后AI 继续追问边界Tag 和 Category 是什么关系需不需要编辑和删除一个问题是只能打一个标签还是可以打多个每个问题都精准收敛范围不扩需求、不写代码。这就是 grill-with-docs 在闭环里的第一个作用把模糊需求收成可讨论的 MVP。澄清完成后你说这句确认话术澄清确认进入 OpenSpec proposal不要实现。第二步创建变更提案落到四份文件你确认后AI 自动进入 proposal 阶段ai_loop_preflight:stateproposalcan_advancetrueAI 自动创建四份文件openspec/changes/add-question-tags/proposal.md ← 变更范围和动机design.md ← 技术方案specs/.../spec.md ← 行为规格tasks.md ← 任务切片草案然后运行严格验证openspec validate add-question-tags --strictAI 停下来等你确认 proposal。注意提案不是口头讨论是落到四份具体文件里而且必须经过严格验证。这是 OpenSpec 在闭环里的作用把澄清结果固化成可验证的合同。如果 proposal 范围正确你说确认 proposal进入 slice。第三步纵向切片 粒度审计你确认 proposal 后AI 把任务拆成纵向 IssueIssue 1: Tag 创建与本租户可见性Issue 2: 给问题打标签与标签列表展示Issue 3: 跨租户隔离验证Issue 4: 标签编辑与删除仅创建者Issue 5: 浏览器端完整用户路径验证Issue 6: Final QA注意不是按数据库、接口、页面横切而是按业务路径纵切。每个 Issue 都能独立验收。拆完后 AI 对每个 Issue 做 Slice Quality Gate 审计slice_quality_gate:issueIssue 1estimated_minutes45validation_domainsapiacceptance_count4sqg_resultPASS预估时间 45 分钟、验证域是 API、验收项 4 条。过粗的 Issue 会被要求继续拆。这是 to-issues 在闭环里的作用加上 ai-loop 自己的二次质量门禁。如果切片合理你说确认 tasks.md开始推进最早未完成 AFK Issue。第四步Maker 执行 TDD你确认 tasks.md 后AI 先为 Issue 1 生成 Checker Gate——验收合同前置checker_gate:gate_typeunit-behaviorrequired_checksTDD Red, Green, 回归测试required_evidence测试输出, diff 审查pass_iftenant A 创建 Tag 后本租户可查到;其他租户查不到fail_if顺手实现 Tag 管理和 AI 推荐Maker 按 TDD 流程执行。先写 Red 测试锁住业务意图def test_tenant_a_can_create_tag_and_see_it():tag create_tag(tenantA, name技术问题)visible list_tags(tenantA)assert 技术问题 in [t.name for t in visible]def test_tenant_b_cannot_see_tenant_a_tags():create_tag(tenantA, name技术问题)visible list_tags(tenantB)assert 技术问题 not in [t.name for t in visible]然后做最小 Green 实现——只改让测试通过的代码不扩功能。完成后标记 ready_for_checker不是自判 PASS。这是 writing-plans 和 tdd 在闭环里的作用先有验收合同再用测试锁住意图最后做最小实现。第五步Checker 只读验收Checker 是独立的只读角色。它读取 OpenSpec、代码 diff、Maker 证据和 Checker Gate独立审查。第一轮返回 FAIL 和三个具体失败项FAIL1. tenant 隔离测试只验证了查询未验证创建时的 tenant 字段写入2. diff 中包含 Tag 管理页面路由超出 Issue 1 范围3. 缺少标签名唯一性约束测试nextrepairMaker 只修这三项失败项不扩大范围重新提交。第二轮 Checker 返回 PASSPASS evidence3 条 TDD 测试全绿; diff 只包含 Issue 1 范围; 租户隔离覆盖查询和写入两条路径只有 Checker 说 PASS总控才把 Issue 标为 done自动进入 Issue 2。写代码的 AI 永远不能自己批改自己的作业。这是 review 在闭环里的作用。五条核心规则从刚才的完整操作中提炼五条纪律第一不要手工写 Maker 和 Checker 提示词。 总控会根据当前 Issue 自动生成执行提示词包含角色、边界、必跑验证和下一门禁。第二tasks.md 是唯一权威清单。 不要在聊天里维护第二份 TODO状态分裂是后期返工的根源。第三Maker 永远不能自判 PASS。 只有独立 Checker 说 PASS 才算完成。这是消灭AI 自己批改自己作业的核心规则。第四Checker 没过不能进入下一个 Issue。 每个 Issue 必须独立闭环带病推进后期必然返工。第五小修不用走全流程。 低风险改动自动跳过 OpenSpec做最小变更和定向验证。流程重量随风险自动调节。这五条不是理论是真实开发中踩过无数坑总结出来的纪律。如果想系统掌握这套控制 AI 编程的方法我做了一套 12 集实战课程前两集免费帮你建立判断框架和全链路诊断地图。CSDN 搜索「AI 编程实战 Superpowers gstack MattPocockSkills」39 元解锁全部十二集。
)
