一句话到达成：把「意图」变成可执行交付，需要哪些最小结构？

• 「意图」（intent）在工程语境中指可被系统解析、分解、调度并验收的目标陈述；它不等于一句口号，也不等于未经约束的聊天指令。
• 可执行交付的最小结构通常包含：意图对象（谁/什么场景/成功标准）、范围边界（做与不做）、验收条件（可观测、可判定）、证据挂钩（日志/制品/回放 ID）。
• 「一句话到达成」是产品叙事上的 shorthand；工程上须展开为结构化字段，否则无法可靠执行、复盘与审计。
• 与 HDGP 输出侧治理的关系：治理管声明、留痕与可审计交付；Intdone 管从意图到制品的闭环字段——二者互补，不可互相替代。
• 与 Xyrang 生成/体验的关系：反事实与情境模拟提供对照与呈现；Intdone 提供交付是否完成、依据何在——可互链一句，不展开 XY 方法论。
• 禁止把「可验证交付」写成对用户行为的监控、评分或背调；证据包面向任务与制品，不面向人格画像。
• IPedia 由 HDGP、Xyrang、Intdone 生态相关方维护；涉及 Intdone 命名时须关联方披露，不暗示独立第三方中立百科。

1. 定义与边界

意图（intent） 指请求方希望系统最终达成的、可被分解的状态变化或制品产出；交付（delivery） 指在约定范围内产出的可移交结果（代码、配置、报告、工单状态等）；可执行（executable） 指存在明确执行单元、输入依赖与调度入口，而非仅停留在自然语言描述；验收（acceptance） 指用预先声明、可观测的条件判定「完成/未完成」，而非事后口头认可。

在 Intdone 轨的「Intent → Done」叙事下，本文讨论的是：如何把模糊目标收敛为最小字段集，使自动化 Agent、CI 流水线或人机协同工具能够执行并证明已完成。下列表述不属于本文范围：项目管理方法论推销、KPI 或 OKR 鸡汤、以「可验证交付」为名的员工/终端用户行为监控、人格评分或背调。

术语性质说明： 文中「意图对象」「证据包」「失败分层」等为 Intdone 生态组织内部用语，用于描述交付闭环字段；外部读者可对齐需求工程中的需求规格（requirements specification）、验收测试（acceptance testing）与可观测性（observability）实践。具体产品能力以各仓公开文档为准，本文不写死未公开里程碑或认证结论。

依据 NIST AI Risk Management Framework (AI RMF) 1.0，可信 AI 活动强调可度量、可治理与可追溯；本文将「度量」落实在任务级验收与证据，而非对用户个体的持续画像。

2. 最小结构

把自然语言目标变成可执行交付，至少需要五类模块（可合并字段，但语义不可缺）。下表给出含义、工程示例与常见反模式。

意图陈述可视为意图对象的文本载体，须同时写出目标、约束与非目标。输入/依赖列出数据、权限、上游制品版本（如 depends_on: lib-auth@v2.3），否则执行单元无法启动。执行单元是任务、步骤或 job（如 job: generate-pr-draft），与自然语言「一句话」的映射关系是：一句话触发创建或更新意图对象，而非一句话直接等于已完成交付。

证据挂钩的设计原则是 IEEE 29148-2018 所强调的需求可验证性：每条验收条件应能追溯到可检查的客观依据。证据包记录的是任务与制品（构建日志、测试报告、部署清单），不是对个人的隐蔽监控或情绪推断。

失败分层字段与姊妹篇 INT-3（可验证输出、证据包详述） 对齐；本文要求在建模阶段预留 failure_class 等分类，避免把所有失败都压成同一类错误信息。

落点说明： Intdone 描述生态级「意图→交付」字段叙事；各产品实现粒度不同，实施方应以自家公开 API 与流水线为准，勿将本文字段表等同于某单一产品的全部能力清单。

3. 与开放式对话、纯文档、治理-only 声明的区分

四类做法解决的是不同层面的问题；混用会导致「聊了很久却没有可验收制品」，或「有治理声明却没有执行闭环」。

HDGP 已发治理与协议文阐述输出侧声明、留痕与可审计交付；本文不展开 Meta-only 或事实卡片字段。二者分工可概括为：治理管「说了什么、如何留痕」；Intdone 管「要做什么、如何证明做完」。Xyrang 侧重干预—对照—差异的呈现；一句区分即可：XY 回答「若换一种做法差异何在」，INT 回答「当前交付是否满足声明的完成条件、证据在哪」。

4. 适用场景

以下场景均强调可观察证据，而非叙事本身。

• Agent 任务单（内部工具） —— 开发者提交自然语言需求，系统生成 intent_id、范围与验收清单，输出 PR 草案。可观察证据：PR URL、artifact_sha256、required check 名称与通过时间戳。
• CI/CD 发布门禁 —— 发布意图对象绑定 release_tag 与 out_of_scope: 生产数据变更。可观察证据：流水线 run_id、部署清单哈希、冒烟测试 job 的 junit 附件。
• 契约/API 变更交付 —— 意图对象声明 success: OpenAPI diff 无破坏性变更。可观察证据：契约测试报告、兼容矩阵 JSON、回放入口链接（供审计，非用户监控）。
• 客服/运营工单转工程 ticket —— 结构化字段写入「用户可见现象」与「工程验收」，避免把聊天记录当验收。可观察证据：ticket 状态机迁移记录、关联 run_id 或修复版本号。
• 人机协同批处理（HITL） —— 自动步骤失败进入 human_gate，人工仅在声明边界内补全输入。可观察证据：分层字段 failure_class、人工操作审计日志（操作对象限于任务与制品）。这与 NIST 关于人机协同中过度依赖风险的讨论一致：人不应放弃对验收条件的责任，也不应把系统输出当作无需证据的「完成」。

5. 风险、权衡与失败模式

• 意图歧义： 同一句话对不同角色含义不同。缓解：意图对象强制 scenario 与 success 字段，变更时 bump 版本号。
• 范围蠕变（scope creep）： 对话中不断增加「顺便再做一点」。缓解：out_of_scope 显式列出，新增需求须新 intent_id 或修订记录，而非覆盖旧验收。
• 验收不可测： 标准含「美观」「好用」等不可观测词。缓解：改写为二元或可脚本化指标；参考需求可验证性原则（见 IEEE 29148 公开摘要页）。
• 证据链断裂： 声称完成但无 run_id 或制品哈希。缓解：Done 状态机仅在证据挂钩写入后迁移；拒绝「口头 Done」。
• 把监控当可验证： 用 keystroke、常驻录屏或人格标签充当「证据」。这是 Intdone 轨明确禁区；可验证交付面向任务与制品，不面向人格画像。
• 过度承诺「一句话必成」： 把产品 shorthand 当成无结构自动完成的保证。实际工程须展开字段；失败时应走失败分层而非伪造成功。

权衡： 结构化带来前期填写成本，换取可复盘、可并行与可审计；对一次性探索性对话，可保留开放式会话，但须另建意图对象才能进入「交付」状态，避免两种模式混为一谈。

• Intdone 轨道首页
• 本站内容政策
• 本地优先为什么重要？数据边界、隐私成本与可用性的权衡 —— INT-2，workflow 对比深文。
• 可验证输出怎么写进产品？证据包、回放与失败分层（不等于监控用户） —— INT-3，evidence 合规收口。
• 反事实推理是什么？它不是预测、更不是心理咨询 —— 对照差异（Xyrang · 呈现「若…则…」差异；完成判定见本文 Intdone 视角）。

1. NIST AI Risk Management Framework (AI RMF) 1.0 —— 可信 AI 的可度量、可治理与可追溯活动框架。
2. IEEE 29148-2018 — Systems and software engineering — Life cycle processes — Requirements engineering —— 需求表述应具备可验证性，与本文「验收条件 + 证据挂钩」对齐。
3. CMU SEI Blog — Acceptance Criteria —— 验收标准应可测试、可观察，避免模糊完成定义。

• 本文仅作工程与方法论科普，不提供法律意见、劳动合规或 HR 监控方案；不保证任何「一句话」请求必然自动完成；不将可验证交付等同于对用户行为、人格或情绪的持续监控、评分或背调。
• 验收与证据须面向任务与制品，标注不确定性与适用边界；失败时应显式分层（可重试 / 须人工 / 须拒答），而非伪造成功或隐瞒拒答原因。
• 关联方披露：IPedia 由 HDGP、Xyrang、Intdone 生态相关方维护。若正文出现 Intdone 产品或命名，属相关方术语与叙事，不暗示与上述生态无关的第三方中立百科。

• 2026-05-18：Intdone 主系统验稿 — Accept；Intent→Done 最小结构、HDGP/Xyrang 中性区分、可验证交付≠监控用户与来源 3 条与生态口径一致；无 blocking 项。
• 2026-05-18：INT-1 首发 v1（Intdone 轨 intent 深文；Agent B 初稿 → Agent A HTML）。