总结你的 AI Coding 使用经验与工作方法。

核心回答

下面是一种工作方法示例，可结合自己的项目替换具体任务。

我的方法是先把任务和验收讲清，再让 AI 小步实现，用实际执行结果决定是否继续。开始时给它需求、相关入口、现有实现约束和完成标准，让它沿调用链读取必要文件；实现时一次处理一个明确问题，避免把局部需求扩成重构；完成后检查变更差异，运行对应的测试、类型检查或真实页面操作。失败时提供原始报错、复现条件和当前改动，让它根据证据修正。

例如给文章表格增加已有的发布时间字段，我会说明默认位置、排序和列显隐要求，让 AI 复用现有列配置，再针对这几个行为检查。提效来自少做重复查找和样板修改，业务含义、修改范围与验收标准仍由我掌握。

展开说明

上下文应足够具体，而不是一次塞进整个仓库

先给症状、目标和不能破坏的约束，再让 AI 查实际入口、共享组件和相关测试。模型从相似代码推断实现有用，但相似页面未必走同一条调用链，因此要看文件位置和引用关系。长日志只保留关键错误，同时保存完整日志位置，避免截断后把真正原因丢掉。

稳定的构建命令、目录约定和曾反复出错的规则可以放进仓库说明；本次需求与临时假设放在任务上下文。两者分开，能减少旧任务信息影响新改动。

小步是控制变更和反馈粒度

对局部低风险需求，读现有模式、直接实现、做针对性验证就够了；不用为了 AI 额外创建大量设计文档。涉及权限、数据迁移或公共接口时，先明确兼容和回退，再分模块实现。

每一步都看差异：是否动了无关文件，是否另造已有工具，是否改测试去迎合错误实现。AI 解释“已经修好”只是交付说明，真正证据是对应提交内容、执行命令和输出。代码变了但测试结果来自旧版本，也不能沿用。

失败后先分类，再重试

测试断言失败，查输入、业务预期和实际输出；依赖没装上、服务没启动，先修环境；命令没有输出，检查退出码和错误流，不把“没有结果”当作“没有问题”。相同错误反复出现时，应让 AI 明确当前假设和下一项区分性检查，而不是换一种措辞重新生成整套代码。

可能的追问

怎么判断 AI 是否真的提高了效率？

比较相近任务从理解需求到验收交付的总耗时，同时记录审查、返工和遗留缺陷。生成更快但人工排错更久，不一定节省总成本；代码生成比例也不能直接代表交付质量。

AI 和你意见不一致怎么办？

把争议改写成可以核对的问题：文档规定什么、真实入口如何调用、哪个输入能区分两种实现。先执行或回看证据，再决定改哪一边；业务规则缺失时补齐规则，而不是以模型语气是否肯定来判断。

参考资料