这是「AI 之路进阶升级指南」L2 的补充篇，如果你没有写代码的基础也不用担心，这篇介绍在没有写代码经验的情况下，可以怎么用 AI 写代码。

你怎么让 AI 写出真正能用的代码？

我们的目标不停留在跑通一次就完事的 demo，而是在你的项目里，程序能有一定的健壮性，在每个场景都能跑出你想要的结果。

  1. 我不知道怎么描述清楚我要什么
  2. 代码写出来后，我怎么知道它是对的
  3. 代码跑崩了，我怎么告诉 AI 修

这三点不需要编程知识，只需要一套沟通方法。

问题一：描述不清 → RCTFC 框架

GCO（Day 10）解决的是任务描述问题。但 GCO 是给 agent 的一次性指令，不是代码任务的完整描述框架。

代码任务需要一个更细的框架：RCTFC。

R（Role / 角色）：让 AI 扮演什么角色。“你是一个 Python 脚本工程师"和"你是一个经验丰富的后端开发者”，代码质量不同。前者给基础脚本，后者会给模块化、带注释的版本。

C（Context / 上下文）：AI 需要知道你现有的环境。用什么语言、有没有依赖库、代码放在哪个项目里、有哪些已有文件可以参考。不说这些，AI 会从头猜，猜错了你再来回改。

T（Task / 任务）：和 GCO 的 Goal 一致，一句话说明你要干什么。不要说"优化一下"，要说"写一个脚本，读取 CSV 并输出统计摘要"。

F（Format / 格式）：输出的长什么样。数据格式、字段名称、文件位置。这些不说，AI 给的代码能用，但输出可能不是你想要的样子。

C（Constraints / 约束）：和 GCO 的 Constraints 一致。代码任务有更具体的约束类型：

  • 环境约束：只能用标准库，还是可以用第三方？
  • 性能约束：处理多少数据？有没有时间要求？
  • 安全约束：不能写文件、不能联网、不能执行系统命令
  • 风格约束：命名规范、注释要求

缺 Context 是代码问题最常见的根因。AI 不知道你在用什么环境，写的代码跑不起来。

Format 要的不是语法，是形状

这里有一个常见的误解：很多人觉得 Format 需要懂代码才能写。其实不是。

Format 要求的是"结果的物理形状与接口规范"，而不是"代码的具体语法与实现方式"。

不懂代码的人完全可以掌控 Format，只需要区分两件事：

  • 代码级别的格式（不懂没关系）：缩进用 Tab 还是空格、变量用 camelCase 还是 snake_case、底层数据结构怎么表达。这些完全交给 AI 决定。
  • 业务与接口级别的格式（非程序员也能掌控）：数据以什么形式传进来、以什么格式交出去、输出文件放在哪。这是业务规则，不是技术门槛。

你负责定义"房子要几个房间、门朝哪开"，AI 负责去埋水管和拉电线。

怎么提 Format 要求？不用代码，用自然语言加示例：

  • 结构说明：“写一个函数，输入是文件路径，输出是一个字典，包含 total 和 average 两个字段。”
  • 函数签名：“把代码拆成两个独立函数：一个负责读取文件 parse_file(path)，另一个负责计算数据 calculate_data(data)。"（即使你不会写函数内部逻辑，也能指定好这几块积木的名称）
  • 文本/文件格式：“输出的 JSON 文件必须按 key 字母顺序排序，并且每个属性名都要小写。”

正反例对比：

❌ 模糊版：“帮我写个脚本处理这个文件。”

AI 会猜：处理什么文件？CSV 还是 JSON？什么语言？输出什么？猜错了重来。

✅ 清晰版：

角色：你是一个 Python 工程师。 上下文：项目路径 ~/projects/sales，Python 3.12，只有标准库。已有 data/sales_2024.csv，字段是 date、product、amount。 任务：写一个脚本读取这个 CSV，输出每个产品的总金额和平均单价，保存到 output/summary.json。 格式：脚本输出一个 JSON 文件，每个产品一行，包含产品名称、总金额、平均单价三个字段。 约束：不用第三方库；处理空行和异常值；输出 JSON 按 product 排序。

同一个任务，两个描述得到的结果天差地别，AI产出的结果是否达到你的预期，关键在你有没有把任务说清楚。 RCTFC 五要素递进：Role → Context → Task → Format → Constraints

问题二：不知道对不对 → 描述测试用例

代码写出来了，你怎么知道它是对的？

不需要跑一遍所有场景，只需要描述三件事：

正常输入：一个典型用例。“用 data/sales_2024.csv 跑，输出应该是三个产品各一行，总额和平均价正确。”

边界情况：极端但不是异常的情况。“如果某个产品只有一行记录，平均价等于那行的金额。”

错误输入：异常情况。“如果 CSV 里有空行，脚本应该跳过而不是报错。”

这三件事组成最小测试集。不是让 AI 写测试代码，是让你在交付前问 AI：“这段代码能处理这三种情况吗？“然后对照 GCO 的 Output 逐项验证。不记得GCO了？看这一节：Day 11：输出质量检查，AI 给你的东西怎么确定做对了

还有一种方法：不变量检查。和 Day 11 的同名方法一样。对代码任务，不变量守的是底线。“无论输入什么，输出格式必须符合 Format 要求”、“任何情况下不应该抛出未捕获异常”、“文件大小不超过阈值”。

最小测试集用来验具体结果，不变量检查用来守底线。两者配合，覆盖了从"能不能用"到"会不会崩"两个层面。

问题三：代码跑崩了 → 迭代修复

代码跑崩了，很多人会说"帮我修一下”。这个描述太模糊，AI 会猜问题在哪，猜错了再改一轮。

迭代修复的核心是精确描述差异，不是描述问题本身。

❌ “代码跑崩了。” ✅ “运行 python main.py data/sales_2024.csv，报错 KeyError: 'amount'。输入文件有 amount 列，可能是列名大小写不匹配。”

❌ “结果不对。” ✅ “输出 summary.json 里 total_amount 字段是字符串不是数字，期望是 float。”

❌ “帮我优化一下。” ✅ “当前脚本处理 10 万行数据用了 3 秒，目标 1 秒以内。可能的瓶颈是逐行解析，考虑改用 csv.DictReader 或分块读取。”

每一次修复只说一件事。不要一口气说"修 bug + 加功能 + 改格式”。渐进式开发：一次改一处，跑一次，验证一次，再改下一处。

还有一个技巧：最小复现案例。如果问题复杂，让 AI 先写一个最小的复现脚本，只包含出问题的部分。复现脚本跑通了，再扩展回完整代码。这样每次迭代范围可控，不容易引入新 bug。

实操案例：TDD Pipeline

知道 RCTFC 之后，下一个问题是：面对复杂需求，怎么一步步推进？

TDD Pipeline 就是答案。它是一套基于 RCTFC 的多阶段工作流，指导 AI 把需求变代码。每个阶段有独立的输入、输出和审核机制，阶段之间通过固定格式的文件传递信息。

五阶段流程

产品设计(做什么)
    │
    v
技术方案(怎么做)
    │
    v
测试方案(怎么验)
    │
    v
测试代码(Red) ──> 业务代码(Green)

TDD Pipeline 五阶段流水线：产品设计 → 技术方案 → 测试方案 → 测试代码 → 业务代码

  • 产品设计：把模糊需求变成可测试的验收标准（User Story + Acceptance Criterion）
  • 技术方案：调研 API、设计架构、明确组件之间的接口
  • 测试方案：基于技术方案写出覆盖全场景的测试用例
  • 测试代码：先写会失败的测试（Red），锁定预期行为
  • 业务代码：写通过所有测试的代码（Green）

每个阶段结束都过一轮独立审核。这不是 AI 自评，是换个视角专门检查。连续两轮没有 C/H/M 级问题才进入下一阶段。

为什么需要 Pipeline

L2 讲的 RCTFC 是一次性任务描述。但对于复杂项目，一次性描述有几个问题：

  1. 上下文爆炸：一个完整项目的描述可能几千字，AI 读到后面会忽略前面的约束
  2. 错误传播：需求阶段的歧义，到了代码阶段才被发现，修复成本翻了十倍
  3. 缺少阶段性验证：一次走完所有阶段，中间没有检查点，出了问题不知道是哪层漏的

TDD Pipeline 的做法是：把一个大任务拆成多个小任务，每个小任务有明确的输入输出和审核标准。

这背后是 RCTFC 的延伸应用。每个阶段本身也是一个 RCTFC 任务，只是输入不再是"你的想法”，而是"上一阶段的输出"。

用 RCTFC 描述第一个阶段

假设你要让 AI 帮你设计一个"批量翻译脚本"，第一步是产品设计。用 RCTFC 描述：

角色：你是一个产品分析师，擅长把模糊需求拆解为可测试的验收标准。

上下文：
- 用户想要一个批量翻译工具
- 输入：文件夹里的 .md 文件
- 目标语言：英文
- 输出：同名的 .en.md 文件

任务：
基于以上信息，生成用户故事和验收标准。

格式：
- 3-5 个核心用户故事，每个故事用"作为...我希望...以便..."格式
- 每个用户故事 2-3 条验收标准，每条 AC 必须是可二值判定的（能用"是/否"明确回答通过与否）
- 标注每条 AC 的关键程度（key/peripheral）

约束：
- 不做技术实现设计，只描述行为
- 每条 AC 必须能在不写代码的情况下验证
- 关键 AC 不超过总条数的 60%

AI 输出验收标准后，过审核：

  • 每条 AC 是否可测试？（能用"是/否"判定）
  • 是否有关键 AC 缺失？（比如"空文件处理"）
  • 是否有模糊的主观形容词？（“快速"“高质量"这类词要删掉）

❌ 模糊 AC：“翻译速度要快，不能出错。”

这个问题有两个：一是"快"和"不出错"都无法二值判定；二是根本不知道判定依据是什么。

✅ 可二值判定 AC（Key）：“对于输入的任意 .md 文件，必须在同一目录下生成同名的 .en.md 文件。”

这条 AC 的通过条件很明确：检查输出目录，同名 .en.md 存在即为 Pass，否则为 Fail。

审核通过后，进入第二阶段：技术方案。这时候，产品设计的输出成为新技术方案的 Context，而 Format 变成了"API 调研结论 + 组件架构图 + 数据流说明”。

Format 在 Pipeline 中的作用

注意上面两个阶段的 Format 要求。它们完全不同：

  • 第一阶段（产品设计）的 Format：用户故事列表 + 验收标准表格
  • 第二阶段（技术方案）的 Format：API 调研表 + 组件图 + 数据流

Format 就像流水线上的卡槽与接口：前一个工序吐出什么形状的零件，后一个工序才能直接扣上去接力。

Format 决定了每个阶段的输出"长什么样”，让下一阶段能直接读取，不需要猜。这就是 TDD Pipeline 的核心价值。每个阶段的 Format 是下一阶段的 Context，阶段之间通过固定格式的文件传递信息，而不是靠 AI 的"理解力"。

完整的五阶段流程

阶段输入输出（Format）审核重点
1. 产品设计用户原始需求用户故事 + 验收标准AC 可测试性、关键度标注
2. 技术方案验收标准API 调研结论 + 架构设计每个设计决策是否有依据
3. 测试方案技术方案测试用例清单是否覆盖所有关键 AC
4. 测试代码测试用例失败的测试文件测试是否锚定在需求上
5. 业务代码测试代码通过测试的业务代码是否所有测试通过

为什么这不用懂代码

整个 TDD Pipeline 流程中，你作为非程序员只需要做两件事：

  1. 描述业务需求（第一阶段）：用自然语言告诉 AI 你要什么
  2. 审核验收标准（第一阶段结束后）：检查 AI 生成的 AC 是否覆盖了你的真实需求

后面的阶段。技术方案、测试用例、代码实现，都是 AI 根据你的输入自主推导的。

这才是 RCTFC + TDD Pipeline 的真正威力：把"我会不会写代码"这个问题，替换成"我能不能把需求说清楚"。

关于 TDD-Pipeline 更详细的介绍，可以访问 GitHub 上的项目 alexwwang/tdd-pipeline，也可以先看这篇综述：AI 辅助 TDD 全流程：从需求到代码的完整防线。

顺便：项目管理习惯

让 AI 写代码还需要一些项目习惯，不只是描述问题和验证结果：

  • 先计划再执行：用 Plan Mode（只读模式）让 AI 先列出实现方案，确认后再动手。避免 AI 一口气写完一堆代码，最后发现方向错了。
  • 项目记忆：在根目录放一个 PROJECT_STATE.md，记录当前进展、已知问题、下一步计划。AI 每次开新对话都读这份文件，不用重新解释背景。
  • Git 版本控制：让 AI 每次修改都 commit，message 写清楚改了什么。出了问题可以回滚到任意状态。
  • 沙盒策略：在副本上测试，不动原件。特别是涉及文件操作、网络请求的任务。

这些习惯不是必需的，但能大幅降低"改崩了不知道怎么回到上一版"的风险，它们也不涉及学习编程，只要动动嘴或者动动手告诉AI要这么做就好了。

今日收获

  • 会用 RCTFC 框架描述代码任务：Role → Context → Task → Format → Constraints
  • 理解 Format 是"结果的形状"，不是"实现的语法"。不需要懂代码也能写
  • 会用三段测试描述法验证 AI 生成的代码
  • 会用精确差异描述做迭代修复，不靠猜
  • 知道 TDD Pipeline 五阶段工作流如何把需求转化为代码
  • 知道项目管理习惯（Plan mode、项目记忆、Git、沙盒）的价值

L2 到这里就全部结束了。如果你觉得还有不清楚的地方，可以再读读之前的文章，把那些练习再看看，跑一跑，试试新的任务。

这是「AI 之路进阶升级指南」L2 Part 5。下篇是 Day 15 L2 毕业考核。