项目背景
图库承载着用户长期积累的照片和视频。一张照片除了画面本身，还可能包含动态属性、拍摄信息、编辑历史、对象关系与保存状态。因此，哪怕只是为图片编辑增加一个看似简单的功能，也往往会牵动入口分类、画布交互、撤销恢复、AI 等待、内容合成、权限以及保存策略。
这次尝试要解决一个具体诉求：当出现新的图片编辑需求时，使用者只需做简单描述，工具就能生成一份可用于首轮讨论的功能报告。报告需要说明功能入口及其与相邻功能的关系，给出关键页面、体验流程、异常场景与其他建议，并提供方案建议，同时生成一个简单可交互的 Demo。
该工具主要面向内外部的产品、设计与开发人员，帮助其在业务实现的早期探索功能关联项、技术实施边界与难度，完成初步评估，减少后期遗漏与返工；但最终决策仍由人工做出。未来，当多模态与生成式界面逐渐普及时，这套方法也有望支持图片编辑工具的实时生成，真正实现千人千面的编辑体验。
当前问题
直接问通用模型“这个功能应该放在哪里，页面应该怎么设计”，通常很快就能得到答案。麻烦在于，答案看上去完整，却未必适合当前产品。
常见问题有四类：
- 模型不了解产品当前形态。它可能把 AI 修图设计成独立页面，也可能把某个参数型能力提升为一级入口，忽略基础编辑与 AI 修图原本就在同一个工作台内。
- 模型不了解哪些规则不可随意改动。动态属性、撤销历史、对象图层以及覆盖原图，都可能带来不可逆后果；缺少明确规则时，方案往往只覆盖“顺利完成任务”的那条路径。
- 模型难以区分事实与猜测。处理时长、错误码、云端策略、正式文案和视觉 Token 可能被补成“合理答案”，但这些内容缺乏证据，不能直接用于评审。
- 生成结果缺少验收。入口是否错位、异常能否恢复、按钮能否操作、Demo 是否把模拟能力写成真实能力，都需要单独检查。
因此，“需求即报告”需要一条完整的生成流程：先读取产品知识，再做分类和推导，按固定结构产出报告与 Demo，最后检查证据和交互。Prompt 只是启动这条流程的入口。
实践方法
我们尝试把图片编辑的功能拆分成知识库，并通过一个判定机制，帮助梳理新功能在图片编辑里的落实规则。在此过程中，我们看到了阿里云在 D20 大会上的实践。
《Vibe Designing Playbook》把稳定生成所需的信息分成两部分：
- 设计声明说明这个产品里有哪些事实、原则和可复用的设计做法。
- 执行契约规定 AI 的工作顺序，包括何时查资料、何时追问、如何验收，以及失败后回到哪里修改。
Playbook 中的设计声明包含 spec / domain / craft / design / components / template 六层。本案例沿用这六层，并增加 Skill 和 Evaluator 两个执行层。
这是一个完整的从想法产生 PRD，到完整设计界面落实的过程。对我们而言，现在仍处于小步快走的实施阶段；当务之急是在设计前期给出粗略方向，帮助周边及设计团队确认需求范围。重点目标是判断并给出方案及建议，因此在过程中需要做一些取舍。
知识库组成
第一步：通过录屏和相关文档，生成当前功能知识库
- 整合当前已有的界面录屏
- 功能基础结构逻辑
- 整理异常场景及处理方案
- 特殊格式规则（动图 / 3D）
- 功能互斥情况
达成结果：可以让 Agent 根据简单的需求描述，给出功能位置、界面结构的建议，以及技术实现上的风险。输出件：《图库图片编辑_基础编辑知识库》。
第二步：界面样式使用规则构建
第一步划定的是功能规则。当它落实到界面上时，若从 0 开始自主构建，可能产生各种无法预期的界面样式。因此除了基本控件外，还需要提供典型功能的界面模板，让生成的 Demo 更符合实际设计。
- 连续数值调整使用滑杆，并让画布实时反馈；
- 离散样式选择使用缩略图预设；
- 局部语义编辑使用智能选区或手动选区；
- 可移动内容使用对象编辑，确认合成后再扁平化；
- 动态照片使用时间轴；
- 画布外生成使用扩展框；
- 需要参考图时，使用图片选择器和提取项管理。
组件库同时记录控件名称、适用任务和交互语义，AI 据此选择符合任务的组件。输出件：编辑专属组件库、关键界面模板。
第三步：证据边界，在无法判断时给出说明
由于系统复杂度较高，分析过程中可能存在遗漏。我们把结果分成 4 种场景：当没有直接证据时，可以通过推断、假设给出建议，但必须标注。
- 直接证据：可以从当前文档、截图或录屏中直接确认；
- 已确认规则：项目成员已经明确，但未必能从界面上直接看出；
- 推导建议：根据现有结构得出的方案，需要说明理由；
- 待验证假设：会影响方案，但目前缺少产品、研发、算法或合规证据。
输出件：《证据边界说明》。
执行契约组成
有了知识库以后，Agent 仍然不能很好地产出固定、可进入生产流程的内容，所以我们需要制定执行契约，通过它固定判断顺序与输出内容。每一步有输入、有输出，也知道什么时候应该停下来追问。
基础 Skill 接收一句需求。以“自动修复合照中闭眼的人”为例：
希望自动修复合照里闭眼的人，用户可以选择要修复的人并确认结果。
1. 解析任务
先把自然语言转成任务结构：编辑对象是人物眼睛或局部人像，动作是内容修复，结果需要由用户确认。输入是合照，因此还要处理多人选择、无人脸、遮挡和图片不适用等情况。
2. 判断入口与相邻关系
候选入口包括人像精修、消除和美颜。这个需求不是通过参数调整五官，因此不适合直接归入美颜；它涉及局部内容重建，与修复能力更接近。如果产品希望把人像质量问题集中管理，也可以把它作为人像精修的二级能力。
报告需要给出一个主建议，同时写明相邻功能的边界，以及备选方案在什么条件下成立。入口由理由支撑，后续评审才有讨论基础。
3. 选择页面模式
合照要先识别人脸，再让用户选择修复对象。处理完成后，还需要查看前后差异、应用结果或重新处理。因此，这个功能适合组合“人物选择、AI 处理等待、结果确认”三种页面状态，不需要额外设计一个通用 Prompt 输入框。
4. 补全流程与异常
主流程之外，还要覆盖无人脸、单人、多人、遮挡或佩戴眼镜、处理失败、结果不自然、用户取消、动态转静态、合成和保存。当前材料没有给出模型限制和性能数据，对应阈值只列为待确认项。
5. 生成报告和 Demo
报告固定覆盖六项业务诉求。Demo 使用自包含的 HTML、CSS 和 JavaScript 骨架，再按功能替换控件与状态。模拟处理、近似 Token 和非真实算法能力都要在页面或交付说明中标出。输出件：《图片编辑知识库执行方法》。
为了更好地辅助判断，我们还根据经验补充给 AI，整理成一份《图片编辑功能决策表》。它通过功能类型、功能位置、界面样式、跨功能约束机制等细化规则，让 Agent 的每一步判断都有依据。
最后一步是 Skill 封装及反馈成长机制。
未来演进思考
这个过程中仍然缺少一个重要环节：自验证（Self Evaluation）。由于当前知识库构建还不够全面，也没有通过 AI 进行端到端的设计输出，当前 Skill 仅用于初期探索功能关联项、技术实施边界与难度，对功能进行评估，因此还没有细化这一步。
未来，这套知识库也可以支持用户自主生成编辑诉求。例如下发指令：“帮我把这张图片做成 ASCII 风格的装饰画。”
在生成的同时，可以调用现有组件、开放调节项，实现细节微调，并将这套工具保存下来。这样就可以做到千人千面，让不同用户自主生成自己常用的编辑功能。