经常使用 Code Agent/Chat：思考和感想

背景

做了一年的 code review，看大家都用上了 AI 来辅助编程，有一些些小的想法，生成此篇。

做过技术支持的人，应该有很多相似的感受：很多人在描述自己遇到的问题、需求时，往往说不清楚，难以让人理解他想表达什么。极端情况下，他可能就甩你一个小小的不完整的截图，加上一句"这为啥报错啊"，此时我就得和他聊起来："截图更大一些，链接发我看看日志，环境配置、出现场景、版本是什么"。

经过一场"酣畅淋漓"的沟通下来，终于知道对方问题的上下文了，我终于懂你了（你不说我怎么懂，说了才懂有什么意思，你根本不懂我......），此时已耗费了很多时间和精力，情绪也会上升。

上述场景和让 AI 写代码，其实是同一回事。

很多时候，自己觉得把问题说清楚了，AI 却 get 不到，生成一些有的没的，不是自己想要的效果，或者代码今天能跑，明天就报错，改了左边坏右边，整个项目越来越臃肿无序，没有全局观，永远只是聚焦于局部。

问题不在 AI，而在于：AI 不是万能的，并不能替代人，本质上它只是工具。

AI 让零基础的人也能快速产出代码，不管对错，先给你生成一堆代码，就问你：有没有自动生成代码吧？

如果没有经历过大、复杂、困难的项目，只是让 AI 解决一些在自己认知里、觉得困难的问题，会让人觉得 AI 无所不能，甚至觉得 AI 能取代人。

很多自媒体账号拥有大量的粉丝、同时并不具备真实 coding 的能力和开发企业真实项目的场景，他们有一些影响力，就吹捧 AI 无所不能来吸引流量。众所周知，自媒体的尽头是标题党、流量、制造焦虑和和广告变现。（换做是我，开两个号，一个无脑吹捧，一个无脑贬低，收割两拨流量，赚两拨钱，哈哈哈）

站在什么立场，说什么话。以前有上市公司 CEO 在访谈时说以后不用编程了，导致一堆人激动坏了、到处宣扬，他其实是为了宣传芯片算力和拉升市值呢。在商业世界里，大佬们的每一次"预言"往往都不是单纯的技术展望，更多的是一种战略布阵，卖铲子的人希望挖矿门槛越低越好。

汽车普及前，马车夫会觉得驾驭马匹是硬技术；汽车普及后，开车成了基本技能。

AI 编程

常见的坑

语言逻辑混乱、指代不明、前后不一
需求宽泛抽象，大而全，中心点分散混乱，不分优先级
无法预见局部对全局、需求变更可能造成的影响
每次对话当做一个独立任务，不维护工程上下文，想写哪里写哪里
随意创建文件、类和函数，存在大量的重复代码，今天忘记昨天生成的内容
只局限于完成当前任务，不学习吸收消化AI给的答案背后的知识
知识面不够广，对于AI给出的方案，无法根据自己实际情况快速判断
不知道看报错堆栈信息，不会断点调试
没有任何统一的编码规范

策略

拆解复杂任务成简单任务
整理需求点，创建markdown文本记录
使用 AI 先优化需求，形成 Prompt
整理技术栈、代码注释风格、错误处理、边界条件等约束，形成规范文档
和AI对话，让AI输出对需求的理解、提出质疑，对齐需求
理解熟悉工程代码，掌握全局的能力，cover 住 AI 生成的代码

长期计划

偿还技术债，主动学习编程知识技能，理解软件工程基本原则
培养先设计、构思流程，再实现的习惯
锻炼阅读官方文档（尤其英文）的能力，不完全依赖AI，培养独立解决问题的能力
思考 AI 给的方案为什么这么做？去查官方文档理解原理，理解 AI 生成的代码

具体改进策略

学会描述需求

养成习惯：先写需求文档，再让 AI 写代码；先整理思路，再动手敲代码。

对于一个工程，建一个 spec.md 文件，每次加功能先写进去。

用 AI 帮优化需求："我想做某某功能，帮我梳理成清晰的功能点"，再与实际项目相互参考
对齐需求：让它质疑、反问我，复述我的需求，我 reivew 一遍后，查看忽略的点、探索没想到的点

制定"项目宪法"

参考：github/spec-kit: 💫 Toolkit to help you get started with Spec-Driven Development

创建一个 constitution.md，每次让 AI 写代码时，把这个文档当"上下文"，比如包含：

markdown 复制代码

## Tech Stack
- Python 3.12
- pytest + pytest-html + allure
- requests + jsonschema (接口测试)
- selenium + pytest-selenium (UI 自动化)

## Project Structure
tests/
  ├── api/           # 接口测试用例
  ├── ui/            # UI 自动化用例
  ├── fixtures/      # pytest fixtures
  ├── utils/         # 工具类(请求封装、断言等)
  └── data/          # 测试数据

## Coding Standards
- 所有用例用 pytest,不用 unittest
- 用例文件以 test_ 开头
- fixture 统一放在 conftest.py
- 接口请求统一用 utils/api_client.py
- 断言失败必须有清晰的错误信息

## Constraints
- legacy_tests/ 目录的老用例别动
- 新用例必须有 allure 报告标注
- 接口测试必须做 schema 校验

主动分析报错信息

习惯用 AI 后，可能会渐渐失去查看报错的耐心，不管三七二十一，直接把大段的报错给 AI，被动地坐等 AI 给答案。

有时候自己仔细看一下，是可以定位排查解决的。

步骤：

看报错信息最后一行，通常是关键
看堆栈跟踪，哪个文件哪一行出错
开启调试模式，一行一行 Debug，查看关键的变量值等等
一定时间内没搞懂，再问 AI，但把完整报错、相关代码、操作步骤都给它
尝试自己搜索 Google

磨刀不误砍柴工。 花时间理清需求、建立规范、学习基础，看似慢，实则是最快的路。

学习不是线性的增长。前期可能是漫长的积累爬坡，后期才有可能快速上升。

大量有效的训练是必要的。就像学开车，一开始慢慢来、打好基础，后面才能真正"飞驰"。