AI 协作完整流程：从任务输入到可验证产出-尧图网络科技

AI 协作完整流程：从任务输入到可验证产出

版本：2026-07-16
适用对象：使用 AI 处理写作、研究、代码和知识工作的个人或小团队
核心目标：让 AI 不只是“生成答案”，而是参与一套可审阅、可验证、可回写、可演化的协作闭环。

1. 这套流程解决什么问题

AI 的生成能力不断提高后，真正的瓶颈逐渐变成：人是否理解 AI 做了什么、是否发现了错误、是否知道哪些内容可靠，以及如何把人的决定准确传回下一轮执行。

一套完整的 AI 协作流程需要同时解决以下问题：

简单任务不能被过度流程化。
复杂任务不能收到请求后直接执行。
事实、来源、未知项和 AI 推论必须分开。
计划和执行之间需要独立审查。
执行必须限定在已授权范围内，并保留停止或回滚路径。
结果必须对应可验证的验收条件。
人的批注、选择和参数调整必须能回写到事实源。
有价值的经验需要沉淀，但不能把一次经验包装成普遍规律。

这份文档给出的是一套可裁剪的协作框架，不主张所有任务都必须走完整流程。

阅读前：术语速查

术语	中文解释
Agent	智能体；能够读取上下文、调用工具并执行多步骤任务的 AI
Human-in-the-loop	人在回路；人持续参与审阅、判断、批准和反馈，而不是完全放手
Outcome Contract	结果契约；对完成定义、验收条件和验证方式的书面约定
prompt	提示词；用户给 AI 的任务说明、上下文、约束和输出要求
mockup	界面草图；用于展示布局、内容和交互方向的设计样稿
PR	Pull Request，代码合并请求；把代码变更提交给他人审查和合并的机制
diff	差异；两个文件或版本之间具体发生的增删改
canonical source	唯一事实源或规范源；长期维护并作为最终依据的数据或文件
view/control surface	视图或控制面；帮助人理解、比较和操作事实源的界面
reflection	反思记录；任务完成后对结果、失败和流程改进的总结
decision log	决策日志；记录选择、理由、审批者和时间的长期文件
Schema	结构约束；规定 JSON、YAML 或其他数据必须包含哪些字段和类型
lint	静态规范检查；不运行程序就检查代码或文档格式问题
ADR	Architecture Decision Record，架构决策记录；保存重要技术决定及其理由
dashboard	仪表板；集中展示指标、状态和异常的可视化页面
token	文本计算单位；模型处理和生成内容时使用的基本计量单位
GFM	GitHub Flavored Markdown，GitHub 风格 Markdown；支持表格和任务清单等扩展语法

2. 从 HTML effectiveness 文章得到的启发

作者明确观点

Claude 官方文章《The unreasonable effectiveness of HTML》认为，当 AI 开始生成越来越复杂的计划、报告和说明时，Markdown 会在视觉表达、交互和分享方面显得受限。

作者明确提出 HTML 的五类优势：

信息密度：可以组合表格、CSS、SVG、图片、代码和空间布局。
视觉清晰度：可以使用标签页、导航、颜色、图示和响应式设计组织长内容。
分享便利：HTML 可以直接在浏览器中打开或通过链接分享。
双向交互：可以加入滑块、拖拽、表单、实时预览和复制按钮。
上下文摄取：AI 可以读取代码库、Git 历史、协作工具或其他数据源，再生成面向人的报告。

文章展示的使用场景包括：

多方案探索和并排比较；
实现计划、界面 mockup 和数据流说明；
PR 审查、代码理解和带批注的 diff；
动画、交互和参数调节原型；
研究报告、技术解释器、状态报告和事故报告；
工单排序、配置编辑、提示词调优和数据标注等一次性编辑器。

作者最终强调，使用 HTML 的根本原因是让自己更能留在与 AI 的协作回路中，而不是把任务完全交给 AI 后不再认真审阅。

分析推论（有限置信度）

以下内容是由文章案例启发的分析，不是文章已经通过实验所证明的结论：

Human-in-the-loop 首先是界面问题。AI 越能独立完成复杂任务，人类监督越需要良好的比较、解释和反馈界面。
HTML 可以成为任务专用控制面。人不只是阅读结果，还可以在界面中排序、调参、批注和做选择。
一次性软件开始变得经济。过去不值得专门开发的临时编辑器，现在可以由 AI 为一次任务生成，用完即弃。
文档可以从静态说明变成可执行工作区。文档不只描述参数，也能让用户调整参数、观察变化并导出结果。
复杂规划可能变成产物网络。探索方案、设计 mockup、实现计划和验证材料可以是相互引用的一组文件，而不是一份超长计划。
混合产物通常比 HTML 最大主义更稳健。Markdown 或 JSON/YAML 保存长期事实，HTML 提供更好的审阅和交互界面。

证据边界

文章明确说明它表达的是作者 Thariq Shihipar 的个人意见。
文章与配套仓库都是 Anthropic 的第一方材料，不是独立研究或系统综述。
文章没有提供 HTML 与 Markdown 的控制实验，也没有证明 HTML 对所有人、所有任务都更有效。
配套仓库在指定 commit 中包含 20 个编号示例，README 说明这些示例是独立 HTML 文件，无构建步骤和外部依赖；这能证明做法可行，不能证明其普遍最优。
本文后续流程属于设计建议，应通过真实任务的结果持续验证和调整。

3. 完整流程的核心原则

原则一：先定义完成，再请求生成

任务开始时先写清楚“什么结果算完成”，再讨论提示词、模型或工具。没有验收标准时，AI 很容易生成看起来完整但无法判断对错的产物。

原则二：状态优先于聊天叙事

长期事实、约束、决定和未知项应进入文件或结构化状态，而不是只保留在越来越长的聊天记录里。

原则三：事实、推论和未知项分层

建议使用以下状态：

VERIFIED：已通过工具、文件或一手来源核对。
CITED：有来源，但尚未独立复核。
INFERENCE：AI 或人的分析推论。
UNKNOWN：当前没有足够证据。

原则四：审查者不能同时充当执行者

复杂任务中，执行者容易维护自己原有方案。独立审查应使用新的上下文或不同 Agent，只读取事实、拆解和验收契约，不参与实际修改。

原则五：按风险增加流程

流程深度应由任务的不可逆性、外部影响、事实不确定性和失败成本决定，而不是由用户消息的字数决定。

原则六：每次交互都应能回到事实源

如果使用 HTML 调参、排序或批注，最终必须能够导出 JSON、diff、Markdown 或 prompt，使人的操作回写到长期保存的规范源。

原则七：验证失败不是润色信号

验证失败时应停止并回到事实、拆解或执行阶段，不能只继续润色文字，让失败显得不明显。

4. 角色与责任

角色	主要责任	不应做的事
发起者	定义目标、范围、约束、权限和验收条件	把高风险决策完全隐含在模糊提示词中
AI 执行者	收集上下文、拆解并执行获批范围	擅自扩展范围或执行未授权外部操作
独立审查者	审核事实、结构、风险、验证计划和范围	一边审查一边修改或为原方案辩护
人工审批者	批准高风险、对外、生产或不可逆动作	在不了解证据和回滚方案时直接批准
产物维护者	维护 canonical source、决策记录和验证结果	只保留聊天结论而不更新长期事实源

角色可以由同一个人在不同时间承担，但“执行”和“独立审查”应保持上下文隔离。

5. 任务分级与流程路由

L0 快速任务

进入条件：低风险、可立即检查、无文件修改、无外部影响，例如翻译一句话、解释概念或提供少量创意。

必需步骤：AI 直接回答，用户快速检查。

可省步骤：事实文件、正式拆解、独立审查、自动化验证和反思记录。

升级条件：开始涉及真实数据、重要事实、文件修改、多步骤交付或用户要求落地。

降级/快速退出条件：答案已经解决问题，且没有产生需要维护的状态或后续动作。

停止条件：出现影响结果的关键歧义、敏感信息或高风险建议时停止快速路径。

L1 标准任务

进入条件：单一产物、风险较低、结果可逆，例如文章草稿、普通总结、单文件修改或初步研究。

必需步骤：目标定义、必要上下文、生成、验收检查和用户确认。

可省步骤：独立 Agent 审查、完整事实格、HTML 控制面和正式反思。

升级条件：任务扩展为多文件、多来源、跨团队、长期维护或结果难以人工快速检查。

降级/快速退出条件：范围被缩小为单一、可直接验证的输出。

停止条件：验收标准缺失，或关键事实无法验证且会显著影响结果。

L2 深度任务

进入条件：多步骤、多文件、复杂研究、代码实现、流程设计或重要决策。

必需步骤：Outcome Contract、事实与未知项、原子化拆解、独立审查、受控执行、自动化验证、人工回写和反思。

可省步骤：若不需要空间比较或交互，可省略 HTML；若没有外部操作，可省略发布审批。

升级条件：涉及生产环境、法律医疗财务、安全、凭据、敏感数据、对外承诺或不可逆动作。

降级/快速退出条件：范围经确认后缩小为单一可逆产物，且没有高影响未知项。

停止条件：独立审查BLOCK、关键事实仍为UNKNOWN、验证计划不可执行或无安全回滚路径。

L3 高风险任务

进入条件：生产变更、资金或合同、法律医疗财务建议、隐私与安全、数据删除、外部发送、公开发布或不可逆操作。

必需步骤：L2 全流程，加领域专家审核、明确人工审批、最小权限、隔离环境、备份、回滚演练和审计记录。

可省步骤：原则上不省略审查、验证、审批和回滚；只能减少与风险无关的展示性产物。

升级条件：已经是最高等级；若风险继续扩大，应停止任务并重新获得授权或专业支持。

降级/快速退出条件：只有在敏感数据、外部影响和不可逆性被实际移除，并经审批者确认后才能降级。

停止条件：权限不明确、专家缺席、回滚不可行、证据不足或请求超出授权范围。

6. 八阶段 AI 协作闭环

阶段 1：目标与路由

输入：用户请求、业务背景、期望结果和已知约束。

动作：复述目标；明确范围内与范围外；识别权限、风险和不可逆性；选择 L0–L3；定义验收标准。

产物：任务简报或 Outcome Contract，至少包含目标、范围、约束、完成定义和验证方式。

闸门：影响最终结果的歧义已经解决；若只是非阻塞细节，可以声明假设后继续。

阶段 2：上下文与事实

输入：相关文件、数据、用户引用、链接、工具输出和现有决定。

动作：只读取当前子任务所需内容；标记VERIFIED、CITED、INFERENCE、UNKNOWN；记录来源和排除项；识别敏感数据。

产物：Context Bundle、事实表、来源清单和未知项列表。

闸门：任何会改变方案或高风险执行的UNKNOWN必须补证据、请求用户决定或阻塞对应步骤。

阶段 3：拆解与产物设计

输入：Outcome Contract、事实表、任务等级和权限范围。

动作：把任务拆成单一关注点的子任务；定义依赖和负责人；为每个验收条件安排验证；选择 Markdown、JSON/YAML、HTML、代码或测试等产物。

产物：任务拆解、依赖关系、产物清单、验证计划和人工决策点。

闸门：每个子任务可独立说明；事实工作有来源；没有把多个风险层混成一个“全部完成”步骤。

阶段 4：独立审查

输入：事实表、任务拆解、Outcome Contract 和领域约束，不提供执行草稿。

动作：由独立上下文审查证据、范围、粒度、风险、权限和验证计划；输出PASS、PASS WITH NOTES或BLOCK。

产物：审查报告、问题等级、批准的子任务和执行约束。

闸门：存在高风险问题、无证据事实或不可验证验收项时必须BLOCK；只有明确批准的子任务可以执行。

阶段 5：执行

输入：已通过审查的子任务、事实表、执行约束和现有工作区状态。

动作：仅执行获批范围；优先最小、可逆修改；保留用户已有变更；记录关键决定；对外部或高风险动作再次确认授权。

产物：文档、代码、分析结果、结构化数据或其他实际交付物。

闸门：不得擅自扩大范围；执行前保留原始状态或备份；无法安全回滚的动作在人工审批前不得执行。

阶段 6：验证

输入：执行产物、验收条件、测试环境和基准状态。

动作：先执行自动化测试、静态检查或数据校验，再做人工语义、视觉和业务检查；逐条映射验收条件。

产物：验证报告、测试输出、未解决问题和置信度说明。

闸门：任一关键验收条件失败都不能宣布完成；验证失败时停止、回滚，或回到阶段 2/3 修订事实与方案。

阶段 7：人工决策与回写

输入：已验证产物、审查说明、剩余风险和可选方案。

动作：人阅读、比较、调参、批注或批准；若使用 HTML，导出 JSON、diff、Markdown 或 prompt；将最终决定回写到 canonical source。

产物：批准记录、决定文件、导出结果和更新后的长期事实源。

闸门：高风险、对外或不可逆动作必须得到明确人工审批；人的界面操作没有导出或回写时，任务尚未闭环。

阶段 8：归档与反思

输入：最终产物、验证报告、决定记录、失败信息和过程指标。

动作：归档可复用材料；删除或隔离临时敏感数据；记录有效做法和失败原因；判断经验是一次性的还是可以形成规则。

产物：reflection、decision log、可复用模板、指标记录和后续任务。

闸门：不得把客户数据、凭据或偶然事实沉淀成通用规则；只有跨任务重复验证的机制才值得升级为流程标准。

7. 产物选择策略

canonical source 与 view/control surface

canonical source指长期维护的唯一事实源或规范源，例如 Markdown、JSON、YAML、数据库或正式代码。

view/control surface指面向人理解和操作的视图或控制面，例如报告页面、交互式 HTML、仪表板或临时编辑器。

核心规则：HTML 可以是出色的view/control surface，但不能默认成为唯一的canonical source。人的操作必须导出并回写到长期事实源。

产物矩阵

需求	canonical source	推荐视图或执行产物	必要验证
简短线性说明	Markdown	Markdown	人工阅读、链接检查
配置、状态、事实格	JSON/YAML	表格或 HTML 表单	Schema、字段和约束校验
多方案比较	Markdown/JSON	HTML 并排比较页	来源、取舍和导出检查
交互调参、排序、标注	JSON/YAML	单文件 HTML 控制面	导出一致性和状态回写
软件实现	代码和配置	IDE、diff、可选 HTML 解释页	测试、lint、构建和回归
长期架构决定	Markdown ADR/决策记录	HTML 图解可选	审批、链接和版本记录
质量保证	测试代码和测试数据	测试报告或 HTML dashboard	自动化测试与人工抽查

HTML 安全风险

脚本执行风险：HTML 中的 JavaScript 是可执行代码，不能因为文件是“报告”就跳过代码审查。
外部网络与资源：默认生成无外部依赖、无网络请求的单文件；确需联网时列出域名、数据流向和用途。
敏感数据：读取代码库、聊天记录或工单生成的 HTML 可能包含内部信息，分享或上传前必须脱敏和审批。
不可信 HTML：不要直接以高权限环境打开来源不明的 HTML；应先审查源码，并在隔离或受限环境中查看。
导出安全：复制 prompt、JSON 或 diff 前检查是否包含凭据、个人信息、内部 URL 或未授权内容。

HTML 维护成本

Git diff 与生成成本：HTML/CSS/JavaScript 容易产生冗长 diff，也通常比 Markdown 消耗更多生成 token 和审阅时间。
可访问性：键盘操作、语义标签、颜色对比、屏幕阅读器和减少动画需要显式要求和验证。
浏览器差异：布局、剪贴板、字体和本地文件权限可能在不同浏览器中表现不同。
内容漂移：HTML 若由源数据生成，源数据变化后页面可能过期；应记录生成时间、来源版本并支持重新生成。
长期维护：一次性编辑器适合临时决策，不应在缺少 owner、测试和升级路径时演变成关键业务系统。

8. 推荐任务目录

L2/L3 任务可以采用以下结构；L0/L1 不必机械创建所有文件。

task-name/ ├── brief.md # 目标、范围、权限、完成定义 ├── facts.yaml # VERIFIED / CITED / INFERENCE / UNKNOWN ├── plan.md # 子任务、依赖、负责人、验证计划 ├── review.md # 独立审查结论和批准范围 ├── work/ # 实际文档、代码或数据产物 ├── report.html # 可选的人类审阅或交互控制面 ├── decisions.json # 人的选择、参数和导出结果 ├── verification.md # 验收条件与验证证据 └── reflection.md # 经验、失败原因和后续改进

9. 可复制模板

任务启动提示词

你将与我协作完成一个任务。先不要直接执行。 目标： [希望最终得到什么] 使用者与场景： [谁会使用结果、在什么情况下使用] 范围内： [允许处理的文件、数据、系统和动作] 范围外： [不能处理或不能改变的内容] 约束： [时间、格式、隐私、安全、兼容性、语言等] 权限： [允许读取、允许写入、必须审批的外部或高风险动作] 证据规则： - 区分 VERIFIED、CITED、INFERENCE、UNKNOWN。 - 不得把未知信息写成事实。 - 关键事实必须给出来源或证据。 完成定义： [列出可逐项验证的验收条件] 流程要求： 1. 先判断任务属于 L0、L1、L2 还是 L3，并说明理由。 2. L0/L1 使用最小必要流程；L2/L3 先建立事实、拆解和审查。 3. 未通过审查前，不执行复杂或高风险修改。 4. 执行后逐条验证验收条件。 5. 明确仍未解决的问题、假设和风险。

独立审查提示词

你是独立审查者，不是执行者。 只读取任务简报、事实表、拆解、验收条件和领域约束；不要修改文件或继续执行任务。 请检查： 1. 每个事实是否有证据，未知项是否被伪装成事实； 2. 子任务是否一个关注点一个步骤，依赖是否闭合； 3. 权限、敏感数据、外部影响和回滚是否明确； 4. 每个验收条件是否可确定性验证； 5. 是否存在过度外推、范围蔓延或过度流程化； 6. 文档或代码的格式规则是否可检查。 输出 PASS、PASS WITH NOTES 或 BLOCK。 任何 High finding 存在时必须 BLOCK，并列出可以执行的批准范围。

HTML 控制面提示词

读取已提供的事实源，为当前任务生成一个单文件 HTML 控制面。 目标：帮助我完成[具体决策]。 受众：[谁会阅读或操作]。 要求： 1. 明确区分事实、来源、未知项和分析推论。 2. 根据任务选择并排比较、流程图、表单或交互控件，不做无关装饰。 3. 关键取舍必须可见，并显示每个选择的代价。 4. 不得编造缺失数据。 5. 默认无外部依赖、无网络请求，并说明安全边界。 6. 支持键盘操作、移动端和打印。 7. 将原始状态保存为结构化 JSON。 8. 提供复制为 JSON、diff、Markdown 或 prompt 的导出按钮。 9. 页面底部列出来源版本、生成时间、假设、局限和待确认事项。 10. HTML 只作为 view/control surface，不替代 canonical source。

10. 完成检查清单

开始前

目标和完成定义清楚。
已选择 L0–L3 任务等级。
范围内、范围外和授权边界清楚。
高风险、不可逆和外部动作已有审批路径。
关键事实有来源，未知项已显式标记。

执行前

复杂任务已拆成单一关注点的子任务。
每个验收条件都有对应验证方法。
独立审查已经通过，并明确批准范围。
已保留原始状态、备份或回滚方案。
产物格式与任务目标匹配。

执行后

只修改了获批范围。
自动化测试、静态检查或数据校验已经运行。
所有验收条件都有证据，而不是主观声称完成。
未解决问题、假设和风险已列出。
人的选择已导出并回写 canonical source。
敏感数据未进入不应出现的文档、日志或分享链接。
有复用价值的经验已记录，无价值临时产物已清理。

11. 典型用法

场景	建议等级	推荐流程	主要产物
写一篇普通内部文章	L1	目标 → 必要上下文 → 草稿 → 人工检查	Markdown
研究一个影响决策的复杂主题	L2	八阶段完整流程，事实与推论分开，独立审查	facts.yaml + Markdown + 可选 HTML 报告
修改多文件代码并准备发布	L2/L3	完整流程 + 测试 + diff 审查 + 回滚 + 人工审批	代码 + 测试 + review.md
调整 30 个工单的优先级	L2	事实导入 → HTML 拖拽控制面 → 导出 JSON/Markdown → 回写	JSON/YAML + HTML
解释一个简单概念	L0	直接回答 → 用户检查 → 结束	对话或短 Markdown