把抽象要求改成可观察条件

「简洁」「高级」「好用」「响应快」「像某个产品」都很难直接验收。它们可以表达偏好，还要继续翻译。

例如「界面要简洁」可以拆成：

• 页面只有一个主要操作；
• 主标题说明当前任务；
• 主要按钮在首屏可见；
• 次要设置默认收起；
• 错误提示靠近对应输入；
• 用户完成以后有明确下一步；
• 移动端不出现横向滚动；
• 文案删除到继续删会改变意思为止。

「处理要快」需要说明输入规模、设备或网络条件、可接受等待、超时处理和进度反馈。不同任务对速度的需求不同，无法只写一个毫秒数字。

参考产品和截图也需要说明借鉴对象。可以参考信息层级、交互步骤或视觉密度，不能让执行者猜测是要复制颜色、布局还是全部行为。涉及第三方作品时，还应避免未经许可的直接复制。

界面任务的最低验收

非设计师也需要具备一套最低检查方法，才能判断设计师或 AI 的产出。可以先确认用户和目标，再检查 Hierarchy、Alignment、Spacing、Color、Contrast、Consistency、文案和实现。^[1]

将这套方法转成验收项，可以检查：

目标与层级

• 页面服务的用户和主要任务是否明确；
• 标题、说明、主要动作和次要动作是否有清楚主次；
• 用户是否知道当前状态和下一步。

对齐与分组

• 同组内容是否沿稳定边线或中心线排列；
• 相近内容使用较小间距，不同区块有更明显间隔；
• 内边距和间距是否来自一致尺度。

可读与可操作

• 文字、背景和控件状态具有足够对比；
• 主按钮与次按钮容易区分；
• 错误、禁用、加载和焦点状态存在；
• 键盘、触摸目标和辅助技术要求按实际平台检查。

一致性

• 同类按钮、表单、卡片和图标保持同类表现；
• 品牌名、大小写、术语和语气统一；
• 不同页面无需重新学习相同操作。

响应式和实现

• 内容变长、变短或缺失时布局仍成立；
• 常用屏幕宽度没有遮挡和溢出；
• Auto Layout、Flexbox 等结构能够表达真实关系；
• 设计工具导出的代码只作参考，仍需人工实现和验收。^[1]

可访问性标准和平台规范会更新，项目应按交付时点检查当前要求。相关案例中的比值和工具示例只能帮助理解，不能代替正式检测。

给 AI 的任务也需要共同对象

AI Coding 的经验建议包括：消除歧义、给出实现细节和相关文档、一次只做有限任务，并在写代码前要求模型重述需求。^[2] 这些做法的目的，是在生成前发现双方理解差异。

一项适合交给 AI 的任务可以包含：

1. 当前项目和目标用户；
2. 允许修改的文件或模块；
3. 输入、输出和完成标准；
4. 相关数据结构、接口和参考文档；
5. 必须保留的行为；
6. 禁止修改的范围；
7. 需要覆盖的正常与异常状态；
8. 要运行的验证；
9. 发现冲突时怎样停下并报告。

执行前先让模型复述任务、列出假设和风险。复述与原要求不一致时，应先修正上下文。任务过大时，按可独立验证的步骤拆开，每次只改变有限范围。

模型输出仍需由能判断结果的人验收。代码看起来完整，可能遗漏权限、重复提交、数据迁移和异常恢复；文章语言流畅，也可能包含无法核实的步骤；界面视觉统一，仍可能没有完成用户任务。^[3][1]

真实密钥、生产数据、客户隐私和高权限账号不应因为生成方便而直接交给不具权限的工具。测试环境、最小权限、脱敏数据、变更记录和人工审批需要根据项目风险设置。

模型、代码工具和设计工具的能力会持续变化。需求文档应描述希望得到的结果，避免把某一版本的提示技巧当成永久流程。

把 AI 任务拆成检查点

一次让模型完成登录、支付、数据库、管理后台和部署，容易让上下文和错误同时扩大。更稳妥的顺序是按可运行结果拆分：

1. 先让模型读取现有结构并复述限制；
2. 只完成数据或接口层，运行对应测试；
3. 再完成一条前端正常路径；
4. 补充空、错、加载和权限状态；
5. 接入外部服务前确认环境和密钥方式；
6. 运行完整验证并人工走查；
7. 更新文档和已知限制。

每个检查点都应可以运行、回退和比较。模型若修改了任务以外的模块，应说明原因；出现需求冲突、缺少权限或无法验证的外部条件时，应停止猜测并交还决定。

AI 网站实践强调一次只做有限任务，并在开始前让模型复述需求。^[2] 这套做法同样适用于非代码工作。文章可以先完成结构和事实表，再写正文；设计可以先确认信息层级，再进入颜色和细节。拆分的依据是可验证结果，不是把一个大要求机械切成几段文字。

模型生成的测试也要接受检查。它可能只验证自己的实现路径，遗漏真实用户会遇到的历史数据、不同权限和失败恢复。项目负责人需要保留独立验收用例，避免实现和验收同时继承同一个错误假设。

数据、权限和支付任务需要额外说明

涉及数据、身份、权限、支付和删除时，一句「接入某服务」远远不够。需求至少要回答：

• 数据由谁创建和拥有；
• 哪类角色可以读取、修改、导出和删除；
• 客户端和服务端分别能接触什么；
• 失败、重试和重复回调怎样处理；
• 历史数据是否迁移，失败后能否回滚；
• 日志记录什么，避免记录什么敏感内容；
• 用户取消、退款或删除账号后怎样处理；
• 外部服务不可用时产品怎样降级；
• 测试环境与生产环境怎样隔离；
• 谁对高风险变更作最终确认。

支付服务还涉及主体、地区、费率、风控和平台政策，它们会随时间与账户变化。^[2] 需求可以写明当前采用的服务和需要验证的条件，不应把历史案例中的阈值、费率或规则直接当成通用配置。

对于不可逆操作，可以增加确认、权限校验、审计和恢复安排。具体控制强度取决于业务风险。需求负责人不必独自给出法律或安全结论，但必须把需要专业确认的事项暴露出来。

外部协作者需要更明确的交付说明

内部成员可以依靠长期背景补全信息，外部协作者通常只能看到当前任务。交付说明至少要包含：

• Scope：本次工作边界；
• Deliverables：源文件、成品、代码、截图、说明或数据；
• Deadline：阶段和最终时间；
• References：示例、品牌规范和技术资料；
• Access：需要的账号、权限和安全方式；
• Review：检查节点和反馈人；
• Revision：包含的修改次数和定义；
• Acceptance：验收标准；
• Handoff：文件、账号、依赖和接管方式；
• Commercial terms：费用、里程碑和超范围处理。

内容外包案例中，详细 Outline 会写入目标关键词、小标题、关键点、技术要求、实际操作步骤、截图和读者结果；可复用 Guideline 则规定 Introduction、正文、Conclusion、截图、Caption 和代码示例。^[3] 每次出现新的质量问题，再把规则补进 Guideline。

这类文档减少的是重复解释。它也让多位协作者在同一标准下工作。规则不必覆盖所有创作细节，仍要给执行者保留专业判断空间；需要统一的是任务、事实、品牌和交付底线。

内容任务也需要事实验收

内容交付很容易只检查字数、关键词和语气。真正可发布的内容还需要完成读者任务，并确保事实可以追溯。

一篇产品教程可以明确：

• 目标读者在开始前知道什么；
• 希望解决哪项具体问题；
• 文章采用什么结构；
• 哪些步骤必须在真实产品中复现；
• 哪些截图需要出现，怎样裁切和标注；
• 代码或命令在哪个环境测试；
• 产品名、术语和链接怎样写；
• 时效性信息以什么日期为准；
• 读者完成后应得到什么结果。

外部内容协作案例会在 Outline 中写入关键词、小标题、关键点、技术要求、操作步骤和截图，再用 Guideline 统一 Introduction、正文、结尾、代码示例和图片规则。^[3] AI 可以协助研究和初稿，实际步骤、截图、代码和引用仍要人工核验。

内容修改也应区分事实错误、未满足结构、表达润色和新增方向。事实错误属于原交付需要修正；临时增加另一类读者或新主题，则可能构成范围变化。