Appearance
需求、规格与上下文
从一句想法到可执行规格
“做一个 AI 网站”无法直接开发。至少需要补齐目标用户、核心任务、输入输出、范围、约束和验收方式。
| 字段 | 示例问题 |
|---|---|
| 用户与场景 | 谁在什么情况下使用？当前怎么做？ |
| 核心结果 | 用户完成后得到什么，而不是系统用了什么技术？ |
| 输入 | 文本、图片、文件、表单、账号状态还是第三方数据？ |
| 输出 | 页面、文件、建议、排序、预测还是自动执行动作？ |
| 范围 | 本轮必须做什么？明确不做什么？ |
| 约束 | 技术栈、目录、品牌、性能、安全、合规和预算有哪些限制？ |
| 验收 | 哪些可观察结果证明完成？错误时应该发生什么？ |
一页规格模板
text
目标：
目标用户：
核心使用场景：
本轮范围：
不在本轮范围：
输入与来源：
输出与去向：
关键流程：
异常与兜底：
数据和权限边界：
验收条件：
需要保留的现有行为：规格不是越长越好，而是让不同人对“做什么”和“什么算完成”没有关键歧义。
上下文分层
| 层级 | 内容 | 更新频率 |
|---|---|---|
| 长期规则 | 项目目标、目录边界、编码规范、安全要求 | 低 |
| 项目事实 | 架构、数据模型、接口、部署方式、关键决策 | 中 |
| 当前任务 | 用户故事、相关文件、验收条件、失败现象 | 高 |
| 临时证据 | 日志、截图、命令输出、测试结果 | 随任务结束归档或清理 |
把所有材料一次性塞进上下文会稀释关键约束。更好的做法是先给目录地图和目标，再让工具按需读取原始文件。
高质量任务说明
一个可执行任务通常包含四部分：
- 结果：最终要改变什么。
- 范围：允许修改哪里，不能动哪里。
- 证据：现状、错误、样例和相关文件。
- 验收：需要运行哪些检查，用户最终看到什么。
例如，不要只说“修一下登录”。应说明登录失败发生在哪个入口、期望行为、已有账号状态、不能改变的安全规则，以及成功和失败两条路径如何验收。
防止上下文失真
- 对动态信息记录日期和来源，不把旧截图当成当前事实。
- 对多个冲突文件标记权威顺序，不让工具自行挑选有利版本。
- 对用户口头补充及时写入当前任务说明。
- 长任务定期总结已完成、未完成、决策和风险。
- 重要数据直接读原文件，不依赖二手摘要。
准备完成后，进入 AI 辅助开发工作流。