**简介：先想清楚“怎样算交付完成、别人怎样复查”，再用 Spec、先红后绿和运行记录，让一次 AI 开发能查找、能复查、能接着做**

## 为什么要建 AI 研发工作台

**简介：直接和 Codex 协作时，难的不是缺材料，而是要求、代码、检查结果对不上**

* 直接协作的三个麻烦

| 麻烦 | 典型问题 | 工作台对应能力 |
|---|---|---|
| 每次接手都要找上下文 | 当时的需求在哪？哪次修改对应哪次测试？ | 任务编号 + 当时的需求 + 多次运行记录 |
| 每次都要核对执行范围 | 这次允许改什么？要跑哪些检查？ | 把确认的范围与检查入口交给执行流程 |
| 失败后很难接着处理 | 卡在哪一步？哪些结果仍有效？ | 保留失败输出、待办和人的决定 |

* 核心问题
 * 聊天适合讨论，Git 存代码版本，文件存需求和输出，各自有用，**难在把它们连起来**
 - 哪段讨论成为正式决定、哪份输出检查的是哪次修改、哪些失败还没解决
 * 不保存对应关系，“最近一次测试通过”很容易被误当成“当前版本满足本次要求”
 * 是否值得建：比较接手速度、漏项、失败能否继续处理，以及维护工作台的成本
 - 任务量少时，文件 + 命名约定也够用，沿用也合理

* 一项开发任务在完整工作台里怎样走完

![为什么要建 AI 研发工作台](https://developer.qcloudimg.com/http-save/yehe-11715263/cadf8a389caa74b56f9b0af3d63473d0.png)

 * 红色节点是人的决定，Codex 说“完成了”不能代替验收
 * 检查失败就按输出修复重跑，要求变化先由人确认

* 工作台固定流程，工程判断仍归人

| 你要判断什么 | 工作台能怎样帮 | 仍可能漏掉什么 |
|---|---|---|
| 真正的使用目的与隐藏条件 | 整理问题、来源和确认后的要求 | 没被发现或问清的条件 |
| 哪些旧代码可复用，改到哪里 | 提供上下文，记录允许范围与改动 | 复用与耦合是否适合当前项目 |
| 怎样判断结果可接受 | 运行约定检查，保留失败与输出 | 测试没覆盖的业务风险 |

* 注意点
 * **流程全部走完、测试全部变绿，也可能仍有未发现的要求**
 * 第一版先做“记录与查询”：后续无论怎样执行，都要先回答“按什么要求做、结果属于哪次工作”

## 从模糊诉求到可验收的 Spec

**简介：先把“下次能接着做”拆成可检查的要求，再写成逐项可验收的 Spec，最后落到写集**

* 六阶段交付链路

![从模糊诉求到可验收的 Spec](https://developer.qcloudimg.com/http-save/yehe-11715263/1a75c2859a9d23cbd3e21690a31219ba.png)

 * 从业务问题开始：“加一个查询按钮”已经选定了解法，却没说清谁遇到什么困难
 * 测试全部通过只说明满足已检查的约定，还要回收使用后的效果
 * 效果回收要预先定好观察对象、时间范围和比较口径，不能把变化全归因于工具

* 三个层次不能互相替代

| 层次 | 例子 |
|---|---|
| 产品目标 | 接手更方便 |
| 可验收行为 | 重启后按编号查回原需求 |
| 实现办法 | 把需求全文写入任务表 |

 * 用了数据库不代表实现正确，实现正确也不一定解决全部接手问题

* 一句“帮我做工作台”还缺哪些决定
 * 要查什么：项目、原需求、每次运行
 * 重复编号怎么办：拒绝，还是覆盖旧任务
 * 什么时候还要查：退出程序、隔天重启后
 * 第一版先不做什么：网页、自动调用 Codex 与自动测试
 * 谁确认完成：自己核对，同伴复核
 * **每个追问都要影响后面的实现或验收，Codex 帮你追问，范围由你确认**

* 从使用条件推导第一版，别从架构名词开始

| 具体条件 | 本次选择与代价 | 怎样检查是否合适 |
|---|---|---|
| 隔天还要查，程序会退出 | 落盘保存，增加持久化实现 | 退出旧进程，再启动查询 |
| 要求会变，旧任务还要复查 | 保存需求副本，多占存储 | 改原文件后旧任务仍读旧要求 |
| 失败后还会修复，历史不能丢 | 每次运行单独追加 | 首次失败与后续通过都能查回 |
| 一人本地、时间有限 | 先用 CLI + SQLite，暂缓网页与远程协作 | 五个操作能完整走通 |

 * 多人并发、大量日志或审计要求出现后，要重新比较存储、权限和运行方式

* 谁建议、谁决定

| 时点 | Codex 协助 | 你的判断 |
|---|---|---|
| 需求访谈 | 追问场景，提出可选方案 | 选择先解决什么，说明理由 |
| 形成 Spec | 整理输入、输出、失败行为与验收项 | 核对并签署具体版本 |
| 准备测试 | 把验收项转成可运行检查 | 确认检查经过真实行为、没漏关键条件 |
| 实现与修订 | 在授权范围内写和修代码 | 核对实际改动，亲自正式复验 |
| 最终复核 | 整理记录与待办 | 结合反馈决定接受、退回或证据不足 |

* Spec 的写法
 * Spec：本次做什么、做到什么程度、怎样检查的书面约定
 * 验收项要写清：前提、操作、预期响应、**操作后的数据状态**
 - 只写“返回错误”，会漏掉“报错前已经覆盖了旧数据”的缺陷
 * 每条关键要求都能回指：原始痛点 → Codex 建议 → 你的决定

```text
项目：个人研发工作台
目标：创建任务后可以按编号查回要求
约定：任务必须属于已登记项目；关闭程序后仍能读取
重复编号：本版拒绝重复创建，不覆盖原任务
验收：创建任务 A，关闭程序后查询，原要求仍在
反例：再次用 A 提交不同内容，应拒绝，原要求与记录不变
```

* 写集（Write Set）
 * 本次允许修改的具体文件集合，例如只改 `workbench/bootstrap.py` 和对应测试文件
 * 发现额外依赖时，先说明原因，再由人决定是否扩范围
 * Spec 中还要写清“本次不做什么”：不自动调用 Codex、不自动判定需求合理、不提供人工验收自动通过

## 第一版数据设计：项目、任务、运行记录

**简介：先列出使用时要查什么，再决定保存什么；项目、任务、运行记录分别保存并建立关联**

* 先看要查什么
 * 选择项目：项目叫什么、代码在哪、新任务属于哪个项目
 * 开发任务：这次做什么、采用哪份需求、做过哪些修改和检查
 * 验收或接手：当时按什么要求检查、哪些测试通过、谁作了决定、理由是什么

* 对象关系：一个项目多项任务，每项任务多次运行

![第一版数据设计：项目、任务、运行记录](https://developer.qcloudimg.com/http-save/yehe-11715263/7410058a80b6303d0166cd814e2575b3.png)

 * 项目说明“在维护什么”，任务说明“这次完成什么”，运行记录说明“实际尝试过什么”
 * **不能只在项目上存“最近一次通过”，否则不知道是哪项任务通过了**

* 需求快照
 * 任务创建时保存的需求全文副本，用稳定编号（ID）关联
 * 只存文件路径的问题：需求文件被改成新规则后，旧任务打开的也是新内容，会拿今天的要求误判过去的实现
 * 快照能追溯“当时依据什么”，但本身不防篡改、不认证身份
 - SHA-256 摘要只能发现内容是否变化，不证明作者或观察时间

* 五个 CLI 操作

| 操作 | 保存或读取什么 | 子命令 |
|---|---|---|
| 初始化 | 所有者、工作台身份、数据目录 | `workbench-init` |
| 登记项目 | 项目名称与代码目录 | `workbench-project-add` |
| 创建任务 | 所属项目、本次需求及快照 | `workbench-task-create` |
| 追加记录 | 运行命令、完整输出、返回码、带时区时间 | `workbench-evidence-add` |
| 查看状态 | 已有记录，指出缺什么 | `workbench-status` |

 * CLI 用 `argparse` 读参数，SQLite 本地保存，程序关闭后数据仍在即持久化（Persistence）
 * 查询命令不能“顺手”创建数据，未初始化或对象不存在时要明确失败

* 失败后状态：拒绝错误请求，还要确认旧数据没被改

| 操作 | 程序应怎样回复 | 还要查询确认什么 |
|---|---|---|
| 在已有项目下创建新任务 | 创建成功 | 任务属于指定项目 |
| 在不存在的项目下创建任务 | 拒绝创建 | 没有留下无所属项目的任务 |
| 用已有编号创建不同任务 | 拒绝覆盖 | 原需求和记录没有变化 |
| 查询缺少运行记录的任务 | 说明缺哪些记录 | 原有记录仍在 |

* 用数据库机制保证
 * 主键：唯一标识一行，例如任务编号
 * 外键：子记录必须属于已有父对象，例如运行记录必须属于某任务，需真正启用外键检查
 * 事务：一组修改整体提交或整体回退，错误请求不能留下“半个新任务”

```text
读取并检查需求文件，得到要保存的内容
开始数据库事务
尝试插入任务编号、已有项目编号、需求副本
如果编号冲突或项目不存在：回退此次写入，报告失败
否则：提交写入，再报告创建成功
```

* 注意点
 * **先删旧任务 A 再建新 A，若新需求文件无效而报错，原任务就丢了**，应尽早校验输入并保证整体失败语义
 * Python `sqlite3` 写入需要提交；同一连接能读到数据，不代表关闭后重新读取也能读到
 * 本次选择“重复编号即拒绝”，其他系统可以允许更新，但必须先说清何时更新、怎样保护旧数据

## 先红后绿：用对照判断能否交付

**简介：测试要经过真实使用条件；先看见失败，再用同一标准看见通过，才能说明检查有效、修复有效**

* 测试必须经过真实使用条件

![先红后绿：用对照判断能否交付](https://developer.qcloudimg.com/http-save/yehe-11715263/43ec4db2b8d8c7a3972bbfc4d45703a1.png)

 * 只在内存里构造数据再检查同一份数据，发现不了“没真正保存”的缺陷
 * 跨进程调用可用 `subprocess`，断言组织用 `unittest`
 * 断言要检查“内容准确”，不能只检查“有内容”或出现“成功”字样
 * 每次用独立数据目录，避免上次残留的 A 让没保存成功的程序看起来正确

* 先红后绿（Red-Green）
 * 红：实现前运行测试并保存失败；绿：实现后用同一输入、同一预期复验通过
 * 前后对照说明：这项检查能识别目标缺陷，修复后行为确实改变
 * 有效红灯必须来自**目标能力缺失**
 - Python 起不来、测试语法错误、导入失败、实际运行零个测试，都不算有效红灯，先排错并保留记录

* “同一测试”的含义
 * 命令文字没变不够，删关键断言、跳过失败用例、换数据目录都可能“变绿却没修好”
 * 复验时核对测试内容的 Diff、代码位置和运行条件
 * 确实是测试写错时，保留旧记录、说明修订原因，再建立新的有效前后对照

* 分清“命令结果”和“人工验收”

| 观察对象 | 示例结果 | 能说明什么 |
|---|---|---|
| 被记录的测试命令 | 返回码 1，查不到任务 A | 该次测试失败 |
| 追加记录命令 | 返回码 0，生成记录编号 | 工作台接收了这条记录 |
| 再次查询记录 | 仍读到返回码 1 和失败输出 | 保存过程没把失败改成通过 |
| 人工验收 | 退回修复 | 功能尚未满足要求 |

 * 退出码：命令结束时返回的数字，0 通常表示成功，非零要结合输出判断
 * **保存成功 ≠ 测试通过，记录齐全 ≠ 人工接受**

| 状态字段 | 含义 |
|---|---|
| `ok` | 本次查询及所要求的检查满足 |
| `evidence_complete` | 记录形成了规定的完整性关系（红 → Diff → 绿） |
| `acceptance: pending_human_review` | 仍等待人工审核，程序不会代签 |

* 验收前整理四项内容
 * 按哪份要求检查：任务编号 + 当时的需求副本，需求改过要区分版本
 * 实际改了什么：看 Diff，每项改动对应哪条要求、是否越界
 * 实际检查了什么：真实命令、原始输出、退出码，对应哪个任务和代码版本
 * 还有什么没证明：失败项、漏测项、待确认问题，由谁决定

* 验收流程

![先红后绿：用对照判断能否交付](https://developer.qcloudimg.com/http-save/yehe-11715263/ad3323c5092283362d5184179d009a80.png)

 * 结论分三种：通过、退回、证据不足，不要笼统写“全都正常”
 * 程序可用但记录缺失，是材料不完整；材料齐全但重复创建仍覆盖数据，是功能缺陷，两者不能都写成“通过”

## 自举：用新工作台记录自己的开发

**简介：工作台建好前先用采集工具保存原始记录，建好后再导入，用自己的工具管理自己的建设过程**

* 先有记录，再有工作台

![自举：用新工作台记录自己的开发](https://developer.qcloudimg.com/http-save/yehe-11715263/c558f61a0d924f78188f88d75d7cebed.png)

 * 自举（Bootstrap）：用新工作台记录它自己的建设过程
 * 验证三件事：能保存、对应正确任务、能查回，失败记录也要原样保留

* 两个辅助工具

| 工具 | 作用 | 注意 |
|---|---|---|
| `evidence.py` | 真实执行 `--` 后的命令，保存输出、退出码、带时区时间、SHA-256 | `red`/`green` 只是阶段名，不会把非零改成成功 |
| `import_evidence.py` | 读取 `meta.json`，调用 `workbench-evidence-add` 导入 | 不重新执行命令，摘要不一致会拒绝导入 |

```bash
# 实现前采集红灯
python -X utf8 tools/evidence.py red -- python -X utf8 -m unittest tests.test_l01_workbench_bootstrap -v

# 实现后用同一命令复验
python -X utf8 tools/evidence.py green -- python -X utf8 -m unittest tests.test_l01_workbench_bootstrap -v

# 让新测试文件出现在 Diff 中（不提交）
git add -N -- workbench/bootstrap.py tests/test_l01_workbench_bootstrap.py
```

* 实践八步

![自举：用新工作台记录自己的开发](https://developer.qcloudimg.com/http-save/yehe-11715263/75c386c273b1e055a5ed8ec0085281f0.png)

 * 隔离区：从缺少目标能力的源码副本开始，核对 `sys.executable` 和模块来源确实在隔离区
 * 签署需求 ≠ 授权实现：先有有效红灯，再确认实现计划
 * 失败后状态：查询不存在的任务应报 `required_task_missing`，再查原任务应恢复通过且数据不变

* 两次签字
 * 开发前：确认“我选择做什么，接受什么范围”
 * 复核后：确认“依据这些结果接受哪些部分，还有哪些问题”，写明接受、退回或证据不足
 * 还没收到同伴反馈就写“待复核”，不能由 AI 代填

* 注意点
 * **不删除失败输出、不改返回码或时间来拼出成功**
 * 中断续做时先查状态，不重复初始化、不清库重演

## 从一次交付到可复用工作台

**简介：Harness 组织执行，记忆系统让历史参与下一次任务，流程蒸馏把真实失败提炼成可复验的方法**

* 三个支撑能力

| 能力 | 解决什么 | 关键点 |
|---|---|---|
| **Harness** | 围绕 AI 任务的运行与控制机制 | 组织输入、工具、检查、返工和停止条件 |
| **记忆系统** | 哪些信息留下，下次何时取出 | 按项目和任务组织，执行前选出相关内容 |
| **工作流程蒸馏** | 从真实经历提炼可复用方法 | 写清适用条件、步骤、检查与停止规则 |

* Harness 的要点
 * 写下“请遵守范围”只是提出要求，执行机制还要检查范围是否被遵守
 * “必须运行测试”只有在检查真的执行、结果被读取并影响后续处理时，才是有效约束
 * 自动重试需要次数或时间上限，以及退出后的状态说明，否则只是更快地重复同一个问题

* 记忆系统的要点
 * 存储只是基础，一百份日志找不到相关记录，记忆就没参与工作
 * 上下文是本次给 AI 的信息，长期材料要经过选择才进入当前上下文
 * 把所有旧聊天塞进输入，既干扰注意，也可能带回过时决定
 * **区分事实与推测**：“怀疑读错数据目录”是推测，“新进程读不到 A”才是事实

* 工作流程蒸馏五步

![从一次交付到可复用工作台](https://developer.qcloudimg.com/http-save/yehe-11715263/0126246fd6f5a76fe288f02b997bee06.png)

 * 例：从“重启后丢失”提炼出“需要长期保存的数据，在新进程中重新读取后再验收”
 * **提炼的是方法（跨进程检查持久化），不是方案（必须用 SQLite）**
 * 候选经验要经过复验和具名确认才成为默认规则，这里更新的是规则和流程，不是模型参数

* 条件变化后重新判断

| 变化 | 要重新想什么 |
|---|---|
| 从一人变多人 | 同一任务同时修改怎样避免后写覆盖前写；哪些操作要授权或并发控制；人数本身不足以决定换数据库 |
| 复用已有保存函数 | 它遇到重复编号是否覆盖旧值；已有调用者是否依赖覆盖行为；按行为差异、影响范围、正反测试选择 |
| 换成文档校对项目 | 任务、需求副本、运行记录可复用；“正确”的验收标准要重新定义，例如引用原文不能被术语替换 |

 * 讨论设计时说出：一个实际条件、一项取舍、一种代价、一个检查方法

## 面试/考试记忆点

* **持续开发要保存的不只是文件，而是“要求、操作、结果、版本”之间的对应关系**
* 产品目标、可验收行为、实现办法是三个层次，不能互相替代
* 验收项要写清前提、操作、响应和操作后的数据状态，只写“返回错误”会漏掉“报错前已覆盖”的缺陷
* 任务创建时保存需求快照，否则需求文件变化后会用新要求误判旧实现
* 持久化测试必须真的退出进程再重新读取，只查内存证明不了能力
* 有效红灯必须来自目标能力缺失，环境错误、语法错误、零测试都不算
* 先红后绿要求同一标准，删断言、跳用例、换目录导致的变绿无效
* 保存成功 ≠ 测试通过，记录完整 ≠ 人工接受，Codex 说“完成了”不能代替验收
* Harness 组织执行，记忆系统选择历史，流程蒸馏把失败经验变成可复验方法
* 提炼的是可迁移的方法，不是把一次实现中的偶然选择当成普遍规则

简介：先想清楚“怎样算交付完成、别人怎样复查”，再用 Spec、先红后绿和运行记录，让一次 AI 开发能查找、能复查、能接着做 为什么要建 AI 研发工作台 简介：直接和 Codex 协作时，难的不是缺材料，而是要求、代码、检查结果对不上 直接协作的三个麻烦 | 麻烦 | 典型问题 | 工作台对应能力 | |---|---|---| | 每次接手都要找上下文 | 当时的需求在哪？哪次修改对应哪次测

以终为始的可验证 AI 交付：Spec、先红后绿与运行记录

人工智能

一次AI开发交付要可查找、可复查、可接续，需先明确“怎样算完成、如何复核”。通过Spec锁定可验收需求，用先红后绿建立真实行为对照，并保存运行记录确保结果对应正确版本。工作台以项目、任务、运行记录三层数据关联历史，保证重启后可查询、失败后可追溯、变更不误判。

数据库

SQLite

Python

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

以终为始的可验证 AI 交付：Spec、先红后绿与运行记录-腾讯云开发者社区-腾讯云

以终为始的可验证 AI 交付：Spec、先红后绿与运行记录

以终为始的可验证 AI 交付：Spec、先红后绿与运行记录

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐