我的项目里，大量代码由 AI 生成和修改。回看自己的工作，最值得积累的是把需求转成明确的业务约束，判断实现是否满足约束，并在失败后找到原因。
代码生成变快以后，这些工作更需要有具体产物：流程、契约、失败样例、测试和可复现的验证步骤。
先给业务动作，再给技术名词
“做一个批量创建功能”范围太大。拆成预览草稿、真实提交、查询状态、重提失败项之后，每一步才能明确谁触发、输入是什么、会改变什么，以及失败后怎么办。
“做一个 AI 网站”也一样。模型列表之外，还有积分成本、用户输入、异步任务、结果保存和部署维护。我需要把这些链路逐步接起来，不能把一页能生成图片当作整个产品已完成。
把限制写成可以检查的契约
AI 不知道项目默认采用什么规则。视频模型支持几张参考图、哪些时长、是否异步，应该落到前后端共用的约束和服务端校验。
计费也需要清晰的失败语义。聊天预扣不足时不能调用服务商；成功后缺少 usage 要走回退费用；外部成功不能因为追加扣款失败而被隐藏。这些具体条件，比一句“保证一致性”更能指导实现。
项目中的计费契约、视频参考素材契约和漫剧预检，就是把自然语言需求继续收敛为可执行规则的例子。
审查时沿着数据和状态走
我会围绕一个业务对象追踪：输入从哪来，哪一步变成内部模型，谁持久化，哪一段调用外部系统，页面最终看到什么。
CSV 引号问题发生在文件与业务值之间；资产重复导入发生在身份、引用和依赖传播之间；Base64 审计问题发生在结果展示与日志持久化之间。它们都说明，只看一个方法是否顺畅，容易漏掉跨层边界。
验收要能推翻自己的方案
正常路径通常很容易演示。更有价值的场景是余额不足、重复提交、部分成功、服务商不返回 usage、页面离开后任务继续、发布后老页面加载新路由。
我把验证拆成三层：关键规则用定向测试检查；跨层行为核对返回值和实际状态；界面流程再用浏览器确认。每层回答不同问题，不能把“测试过了”当成所有使用场景都没问题。
把一次修复变成下次的上下文
AI 协作容易在新会话里丢失项目约定。所以需要把稳定规则留在仓库：请求和返回字段、错误分支、验证矩阵、部署步骤，以及踩坑后新增的检查点。
个人 AI 平台的提交里，计费、媒体输入、资源缓存等修改都同时补充了相关规范或测试。这个习惯让修复不只存在于聊天记录里。
我希望展示的个人能力
- 问题定义：能把模糊需求拆成可执行、可验收的业务动作。
- 技术判断：能解释状态、成本和依赖关系中的关键取舍。
- 定位与纠偏：能从真实失败找到边界问题，再推动 AI 修改。
- 交付验证：用代码、测试和使用场景检查结果，并保留复用材料。
这些能力需要在每次交付里持续验证。项目页和踩坑笔记记录的是具体实践，后续也会随着新问题继续修正。