从一个想法到可交付产品：AI 时代的开发全过程
把问题定义、规格、实现与验收连成一条线。代码生成只是其中一步。
AI 缩短了把需求变成代码的时间，却没有自动解决“做出来的是否值得用”。开发变快以后，最容易被跳过的反而是问题定义、异常状态和验收。要交付产品，必须把需求、实现、验证与运行连成一条可追溯的链。
01 / 定义：交付是行为成立，不是页面出现
一个产品改动至少包含四件事：要改变的使用者行为、实现这种行为的系统规则、证明规则成立的证据，以及失败时的处理方式。代码只是其中的实现载体。页面能点击、接口返回成功，都不自动说明用户问题解决了。
用一个贯穿案例：项目管理员需要导出本项目的工单，方便周会核对。这里“本项目”比“导出按钮”更重要。如果按钮正常、CSV 正常，却包含别的项目数据，这个功能就是失败的。
需求应该能变成输入与预期结果；否则 AI 只能猜测你对“完成”的理解。
02 / 推导：为什么要先做最小完整链路
一次实现列表、筛选、导出、定时发送和权限后台，表面上更完整，实际会同时引入很多不确定性。先让一个授权用户导出一个项目的少量数据，可以验证最重要的关系：身份从哪里来、项目范围如何确定、文件包含什么、如何复核。
最小不是只做正常界面。只要导出涉及权限，拒绝越权就是最小链路的一部分；只要数据可能为空，空结果也是必要状态。所谓完整，是在限定范围内把关键条件闭合。
03 / 应用：把工单导出从需求写到实现
- 定义对象。写清用户角色、project_id、工单字段和归属关系。管理员也必须属于该项目，不能仅凭角色名放行。
- 建立验收表。准备本项目两条记录、外项目一条记录、空项目及无权限用户。先写预期，再写实现。
- 画行为草图。只需表达点击、处理中、下载完成、无数据和失败五种状态。确定失败后能否重试，以及重试是否产生重复动作。
- 让 AI 阅读现有工程。先返回路由、身份来源、查询函数、现有测试和相关约定。未经确认不要引入第二套权限机制。
- 实现一条链路。服务端验证身份与项目权限，用绑定参数查询授权数据，再生成固定字段的 CSV。前端隐藏按钮可以改善体验，但不能替代服务端校验。
- 验证输出。打开下载文件并核对记录与列顺序；名称含逗号或换行时仍能正确解析。对可能被电子表格当作公式执行的用户输入，按产品的数据导出策略进行处理。
- 准备运行说明。记录改动、配置、验证命令、已知限制和回退方式。只有获得部署授权后，才进入对应环境发布。
| 输入情境 | 预期行为 |
|---|---|
| P-01 成员且有导出权限 | 只返回 P-01 的工单 |
| P-02 管理员请求 P-01 | 拒绝，不生成含数据的文件 |
| 授权项目无工单 | 明确提示无数据，或输出仅表头文件；口径一致 |
| 数据库失败 | 显示失败，不把空文件当成功 |
| 文本含逗号与换行 | 再次解析后字段值保持一致 |
把这张表交给 AI 时，要求它标明每条规则由哪段代码和哪项测试保证。如果只能描述“已经考虑权限”，还没有足够证据。
04 / 验收：测试通过之后还要看什么
自动测试擅长重复检查明确规则；浏览器检查擅长发现下载流程、错误文案和小屏幕操作问题。两者都需要，但不能互相冒充。还应检查改动范围：是否顺带修改了无关模块，是否把测试数据或凭据带进仓库。
- 功能证据：实际输入、实际文件和测试结果能相互对应。
- 边界证据：越权、空结果、异常字符和依赖失败都有明确处理。
- 变更证据：能说明每个主要改动服务哪条需求。
- 运行证据：知道错误如何被发现、谁处理、怎样回退。
如果只在本机用模拟数据验证，应写“本地验证通过”，不能升级成“生产可用”。性能、真实身份系统与生产数据规模还需要对应环境的证据。
05 / 迁移：新增需求时沿链路找变化
如果下一步加入“每天自动发送导出文件”，这不是给按钮加个定时器。它增加了收件人授权、敏感信息外发、重复发送、失败重试和取消订阅等规则。先补这些规则与验收，再让 AI 修改实现。
练习：用户要求“导出更快”，第一步应该改查询吗？
先区分等待发生在查询、生成文件、网络传输还是浏览器处理，并记录数据量和耗时。没有测量就改查询，可能优化错地方。若主要成本来自超大导出，可以考虑异步任务，但要补状态、恢复和文件权限。
具体代码协作进入Claude Code 日常开发；长期可靠性进入自动化与质量控制。产品层保留“为什么做、什么算完成”，工程层负责把它落到可执行证据。