开发承诺（Development Promise） 众多角色（开发、测试、BA、PM 等）共同制定功能检查点和系统边界测试计划 A / BA： 开发者提出功能构想及检查点划分B： 测试人员在 A 的基础上细化为可执行测试策略与用例
优势：提前明确预期行为、优先级、测试覆盖范围，并形成不可造假约束。 在 AI 场景下，skill.md 定义 AI 功能指令，而 TestPlan.md 定义功能检查点或系统边界。
TPDD 的传统应用场景模式
在 TPDD 中，开发者协助测试人员起草 测试计划 A（开发承诺 / Development Promise），再进行实际开发。
开发承诺 / 测试计划 A 的结构：
Must Have – Critical Check Points必须完成的功能点，未完成视为工作未完成测试重点：功能验证 + adhoc 测试高能力团队可纳入自动化测试Need Have – Important Check Points重要功能点，必须完成大部分测试重点：功能验证Should Have – Optional Check Points可选功能，由开发者决定实现与否测试重点：手动测试
1. 背景与趋势
2018 年，我提出过测试计划驱动开发（TPDD），试图以一种比 TDD 更友好的方式组织开发流程。八年过去，技术世界已经发生深刻变化。
大模型正在显著加速软件开发范式的演进。以 ChatGPT 等为代表的生成式 AI，已在实际工程中明显提升开发效率，许多过去需要人工完成的编码与调试工作，正在被模型部分甚至大规模接管。
与此同时，自然语言直接生成程序的能力也在快速成熟。随着 Agent、Skill 等技术与新概念的出现，少量程序员，甚至非科班人员，仅凭自然语言描述，就能够生成可运行程序。这种从“写代码”到“描述意图”的转变，正在重塑软件生产的基本形态。
更关键的是，这一能力并未停留在玩具级 Demo。经过多轮迭代与工程化实践，以自然语言为入口、以智能体为执行核心的开发方式，已经开始具备支撑 SaaS 级应用的现实能力。进入 2025 年，这一趋势进一步加速。Agent 与 Skill 体系逐步成型，使开发者可以在数月、数周，乃至数小时的连续迭代中，生成结构完整的大型项目。从原型验证到功能闭环，再到初步可用的产品形态，AI 正在实质性压缩软件生产周期，并已在部分场景中支撑 SaaS 级应用开发。
到了 2026 年，AI 的爆发呈现出明显的“破圈”特征。个人智能体（Personal Agent）的推出，彻底点燃了公众关注度。Agent 不再只是从业者圈内的效率工具，而是开始走向大众使用场景；它也不再停留在实验室或概念验证阶段，而是真正迈入普及化工具时代。
在这一阶段，个人或小团队可以通过 AI 完成代码生成、应用部署乃至运营管理，但与此同时，风险与责任也出现高度集中。
换句话说，Agent 正在完成一次关键跃迁： 研究原型 → 工程工具 → 公众基础设施。
这一步跨越，意味着软件生产方式与人机协作结构，正在进入新的历史阶段。
2. 核心问题
随着 AI 深度介入开发过程，一种新的生产路径正在形成：想法 → 说出 → 描述 → 生成
自然语言第一次成为“可执行接口”。开发流程被极度压缩，但与此同时，系统内部逻辑的可见性正从白盒逐渐滑向灰盒，甚至黑盒；越是如此，对 AI 的依赖反而越高。
随着对 AI 依赖的不断加深，代码的可控性却在相对下降，不可控性与潜在风险同步放大。（增强说明：例如使用第三方 Skill 或 Agent 时，如果未进行沙盒化测试，可能导致敏感数据泄露或系统破坏）
基于大量实践观察，我将当前主要风险来源归纳为三点：
使用 AI 的策略失衡团队 QA 能力与质量意识缺位组织文化与流程发生冲突
在 OPC 或单人团队模式下，这三类风险往往集中到个人身上，意味着个人需要同时承担开发、运维、安全、合规与财务责任。
2.1 能力暴露与禁止空间的结构性失衡
在大量 AI 使用实践中，一个被普遍忽视的事实逐渐浮现：多数团队专注于“还能让 AI 做什么”，却缺乏“AI 绝对不能做什么”的系统性思维。
这类似于操作一台功能极其强大的自动化系统，却没有设置安全边界。再先进的自动驾驶汽车，也必须配备方向盘、安全带与安全气囊；AI 同样需要明确的限制与保护机制。
在 AI 工程中，理解模型“能做什么”和“不能做什么”同等重要：
能力暴露（Capability Exposure）：定义能力边界禁止空间（Forbidden Zone）：定义安全边界
二者本应是一体两面，但现实中绝大多数团队严重偏向前者。
许多使用者只关心：用了什么 Skill、搭了什么 workflow、选了哪个 model，却很少关注系统验证与边界控制，甚至缺乏基础测试，更多依赖“感觉不对就让 AI 再改”的试错模式，更遑论系统级红线设计。
能力暴露（Capability Exposure）
Skill 的本质，是对 AI “能做什么”的结构化表达。例如：
功能：生成报表输入：CSV 数据输出：PDF 文件调用方式：agent.run("生成报表", data)
当前主流心智模式是： 我要实现什么 → 让 AI 做更多 → 不断补丁式修正，这种模式在能力扩展上极其高效，但在约束缺失时，也极易放大系统风险。
禁止空间（Redline / Forbidden Zone）
相比之下，“不能做什么”往往被系统性忽视。许多 AI 系统没有明确的禁止空间定义，只在出问题后被动修补，例如 OpenClaw 不推荐在主力机上使用，因为存在大量安全问题。（增强说明：建议所有第三方 Skill / Agent 都在沙盒或备用机环境中运行）
典型风险包括但不限于：
Prompt injection 导致敏感信息泄露自动删除或覆盖本地文件越权访问企业知识库浏览网页后向外发送内容对 XSS 或提示注入缺乏防御
没有防御性规范的 AI 系统，本质上是高能力、低护甲的高风险体。
值得注意的是，TPDD 的高层测试计划天然可以缓解这一问题：通过提前定义测试点与边界条件，使 AI 在执行阶段始终处于可约束空间内，从而在能力利用与风险控制之间取得平衡。（增强说明：可以通过 TestPlan.md 定义每个 Skill 的边界、禁止操作、异常路径触发条件）
2.2 QA 思维的系统性缺位
即便部分 AI 使用者具备基本验收意识，对产品质量的整体把控仍普遍不足。常见状态就是：功能能跑通 → Happy path 通过 → 即视为完成。
这种模式在传统开发时代就已存在，而在 AI 时代被进一步放大，而更关键的是：AI 使用者本身，正在天然转变为质量把控者，仅做表层测试已远远不够。
Failure Thinking 是保证 AI 自动化生成代码可控、可维护的核心手段。 使用者必须同时具备：代码阅读与审计能力、需求一致性判断能力、系统风险识别能力。
这意味着，每一个 AI 使用者都需要具备一定程度的抗风险 mindset——以批判性与怀疑性视角审视系统，以安全与需求为底线，持续评估系统的稳定性、正确性与安全性，而 QA 的核心能力，恰恰天然契合 AI 安全落地需求，包括但不限于：
边界条件思维异常路径覆盖非法状态识别失败模式分析防御性设计意识
相比之下，单纯开发导向的实践，往往系统性缺乏 Failure Thinking 与禁止空间意识。
因此，在 AI 深度参与的软件体系中：
QA 不再只是角色，而是一种必须被团队共享的工程心智TPDD 的价值之一，正是在流程层面让不同角色、不同背景的人都能参与到测试计划与约束设计中，形成多视角监督，从而共同承担 AI 的安全性与功能正确性责任在这个过程的同时，不仅是开发人员，所有的参与者将会一起提升
通过引入 TPDD，所有 AI 使用者——不仅仅是 QA——都会参与测试计划的设计和边界定义，从而直接或间接地掌握基本的测试知识。更重要的是，这种做法将 QA 思维方式扩散到整个团队。
2.3 团队分化与文化的应对方式
当前行业对 AI 的使用正在出现明显分化。不同团队与个人，在“是否采用”“采用深度”以及“嵌入流程位置”上，逐渐收敛为两种典型路径：
两者的本质不在于是否使用 AI，而在于：是否为 AI 建立了足够强的工程约束体系。高产型团队往往把 AI 当作生产力放大器，却低估了不确定性扩散的速度；而克制型团队更早意识到，大模型在提升生成效率的同时，也同步放大了系统状态空间与潜在失效面，因此会主动构建结构性护栏。
可以预见，随着 Agent 从实验室工具走向公众基础设施，真正能够穿越周期的，不会是“生成速度最快”的团队，而是那些最早完成 AI 工程化闭环设计的团队。而这，正是 TPDD 与高层测试闭环方法论试图系统回答的问题。
3. TPDD 在 AI 开发时代的价值
TPDD（Test Plan Driven Development） 的核心思想是：用测试计划驱动设计。在这种模式下，开发者会参与测试计划的制定，而后再开展开发，同时包括 BA、PM 和 QA，从而明确系统需求、优先级以及边界条件。
在讨论 TPDD 之前，不可避免要提 TDD（Test Driven Development）。TDD 在传统软件开发中非常重要，其核心目标是确保代码质量和可测试性。但在 AI 开发时代，TDD 流程逐渐被 AI 内化：
单元测试和代码生成自动化，由模型直接完成细粒度验证被 AI 自我校验替代开发者不再直接参与每次单元级循环
也就是说，TDD 的价值依然存在，但执行路径已经被 AI 替代，就像我们不必亲自浇水种土豆一样。未来，单元测试可能完全由 AI 内化，而再上一层，测试计划将成为控制 AI 行为、检测功能是否符合预期的最后防线。
AI 场景下的核心问题
随着 AI 内化单元验证，工程治理重心发生迁移。团队必须回答三个关键问题：
功能应该是什么边界在哪里什么叫真正的“通过”
TPDD 策略是：先定义系统必须满足的条件，再允许 AI 去实现，同时始终保持人类对边界的控制和验证。
TDD 与 TPDD 的对比
相比 TDD 注重细粒度单元测试，TPDD 更关注高层测试计划：先定义核心检查点、必须通过项和优先级，再回到代码开发与测试细化阶段。
核心组成
开发承诺（Development Promise） 众多角色（开发、测试、BA、PM 等）共同制定功能检查点和系统边界测试计划 A / BA： 开发者提出功能构想及检查点划分B： 测试人员在 A 的基础上细化为可执行测试策略与用例
优势：提前明确预期行为、优先级、测试覆盖范围，并形成不可造假约束。 在 AI 场景下，skill.md 定义 AI 功能指令，而 TestPlan.md 定义功能检查点或系统边界。
TPDD 的传统应用场景模式
在 TPDD 中，开发者协助测试人员起草 测试计划 A（开发承诺 / Development Promise），再进行实际开发。
开发承诺 / 测试计划 A 的结构：
Must Have – Critical Check Points必须完成的功能点，未完成视为工作未完成测试重点：功能验证 + adhoc 测试高能力团队可纳入自动化测试Need Have – Important Check Points重要功能点，必须完成大部分测试重点：功能验证Should Have – Optional Check Points可选功能，由开发者决定实现与否测试重点：手动测试
作用：
明确优先级，提供开发与测试指导
对开发者：理清任务优先级，快速理解任务，即使团队成员离职或请假，其他开发者也能迅速开展工作对测试人员：明确重点测试、实验性测试以及需自动化的功能，提高测试效率并顺利整合 CI/CD
促进开发者谨慎编码，提高质量
利用心理学“承诺效应”，开发者会自然约束行为，确保开发过程与承诺一致知道至少要通过哪些测试，从而提升代码可靠性和整体质量
优化测试人员工作流程
测试人员可在测试计划 A 基础上起草 测试计划 B，明确具体测试方法为自动化测试、adhoc 测试及运维工作争取更多时间
4. TPDD 的AI场景应用
正是这一心理学效应，使 TPDD 的开发承诺机制能够有效提升团队执行力、代码质量和系统可靠性。
随着 AI 的逐渐强大，自动化生成代码和测试用例已成为可能。曾经需要程序员手动思考的“怎么开发”，在今天已经被 AI 内化——代码生成、测试验证、循环迭代，都能自动完成。那么，我们还能做什么？答案是：设计、调整和规范测试。也正因为如此，TPDD 再次成为主流，其价值被重新凸显。
九年前，我所提出的，TPDD 只是“测试计划先行”的理念，强调团队共识、边界定义和高层控制。而在今天，AI 可以自动生成代码和测试用例，这种“高层先行 + 验证闭环”模式，天然契合 AI 的执行逻辑。开发者不再需要手动验证每条单元测试，AI 已经内化了 TDD 的精细循环；而 TPDD 的高层规划则提供了宏观控制、边界约束和失败模式定义——正是 AI 最缺乏的能力。
TPDD 天然解决了 AI 的最大痛点。AI 可以生成功能，但缺乏边界意识、Failure Thinking 和禁止空间。TPDD 早就把这些概念融入流程：明确边界、优先级划分、必须通过的核心检查点……这些正是 AI 在自动化执行时所急需的安全约束和指导。
换句话说，TDD 被 AI 内化执行，TPDD 则提供了宏观控制和安全保障。高层测试计划 + 核心检查点，在 AI 场景下成为天然适配的框架，让开发不仅高效，而且可控、安全、可持续。
保留专门作用于能力暴露（Capability Exposure）的 Skill.md 所擅长的能力，并将其与 TPDD 结合，相当于形成一个安全与质量的 Skill.md。
在实践中，可以使用一个类似 Skill.md 的 AI 指示文件，例如 TestPlan.md，或者任何其他命名方式。其最核心的目的只有两件事：TestPlan.md = 内部限制 + 外部验证
内部限制：定义 AI 可做与不可做的操作边界，将禁止空间显式化，防止越界和潜在风险。外部验证：提供可执行的高层测试规范，使 AI 在生成代码或执行操作时，能够自动参考并遵循这些边界与检查点，实现持续验证与安全保障。
内部限制 禁止空间（Redline Definition）
内部限制明确禁止操作、非法组合、不可接受副作用建立系统边界与安全沙盒
外部验证 验证计划 （Verification Plan）
外部验证核心：可观测验证系统是否按预期运行Must Have：核心功能，必须通过Need Have：次要功能，必要验证Should Have：可选或附加功能
工具映射：
TestPlan.md ← 测试约束skill.md ← 能力暴露redline.md ← 禁止空间 （也可以将内部限制和验证分开存放）
5. TestPlan.md 示例：AI 生成销售报表
功能描述 (Capability)
功能名称：生成销售报表输入：CSV 格式销售数据（包含日期、产品、数量、单价、地区等字段）输出：PDF 或 Excel 报表调用方式：agent.run("生成销售报表", data)可选参数：报表模板、汇总方式（按产品/按地区）、日期范围
能力边界 (Boundary)
禁止空间 (Forbidden Zone / Redline)
不允许访问非报表相关本地文件不允许上传或发送敏感客户数据到外部服务不允许删除原始 CSV 文件不允许调用未经授权的第三方 API不允许执行任意代码（防止 RCE）
测试策略 (Validation Plan)
Must Have 核心功能
输入有效 CSV，生成 PDF 报表报表内容正确，包括汇总、统计和图表调用超过 50 次触发限制时返回错误提示
Need Have 次要功能
支持不同报表模板支持按日期或地区筛选数据支持 Excel 格式输出
Should Have 可选功能
支持自动邮件发送报表支持报表加密（可选密码保护）支持自定义字体和颜色（仅内部批准模板）
异常路径 (Failure & Edge Cases)
审计与日志
每次生成报表必须记录调用用户、时间、输入数据摘要、输出文件名异常触发必须记录完整日志，并告警到管理员
Token / 安全约束
每次生成报表消耗 1 Token当 Token 剩余 < 10 时，触发提醒沙盒环境执行，避免主机或生产数据库风险
6. CTO 行动建议
保留 TDD，但不再是最高控制层强制 AI 功能配套 TestPlan.mdMust / Need / Should 分级验证外部验证优先第三方 Agent / Skill 沙盒运行Token 预算护栏渐进式生成代码
系统可靠性取决于不可绕过的测试计划，而非单元测试覆盖。
7. 长远价值与总结
TDD 的内化，使 TPDD 高层测试计划成为 AI 开发闭环的天然工具。
Development Promise + Test Plan A/B + Verification Plan 将共同构建可控、可维护、可扩展的软件系统。
在 OPC 或个人开发模式下，安全、沙盒化与 Token 控制已成为必选项。
TPDD 不仅是一套流程，更是一种工程心智，用于确保团队或个人在 AI 高产环境中仍能牢牢掌握系统可靠性。
最终结论：在 AI 开发时代，能力暴露与禁止空间必须并行；速度不再是第一目标，可控、可维护、可扩展，才是能够穿越周期的长期价值。
作者介绍：
臧嘉玮，资深软件验证工程师与技术布道者，AI 探索者，曾贡献 1000+ 条维基百科与百度百科条目。精通自动化测试、开发策略优化及前沿测试技术，致力于将复杂系统验证经验与 AI 应用转化为可复用实战洞察。曾任 IBM 测试顾问、Siemens EDA 核心测试与自动化工程师，同时是 TPDD（Test Plan-Driven Development）方法布道者。