> For the complete documentation index, see [llms.txt](https://mashihua.gitbook.io/everyone_is_a_programmer/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mashihua.gitbook.io/everyone_is_a_programmer/qian-yan-yi-ge-zhao-pin-tie-yin-fa-de-si-kao.md).
# 前言：一个招聘帖引发的思考
某天，我在一个技术社群里看到这样一条消息：
> "需要资深技术顾问，AI Coding 专家，帮我的一个客户解决 AI Coding 后 BA1 开发的代码和后端整合的问题，代码丢失，合并困难，冲突，付费咨询指导，有同学有兴趣的联系我。"
我盯着这条消息看了很久。
不是因为它罕见，而是因为它太典型了。
这条帖子里藏着三个值得细细品味的细节。
第一，**出了问题，第一反应是找"AI Coding 专家"**。好像这些问题是 AI 带来的新问题，需要懂 AI 的人才能解决。但仔细看看问题本身——代码丢失、合并困难、前后端整合不了——这些问题跟 AI 没有半点关系。这是二十年前就存在的工程问题，根源是没有版本控制、没有接口约定、没有协作规范。一个 2005 年入行的工程师，闭着眼睛都能告诉你怎么解决。
第二，**BA 在用 AI 写代码**。这本身没有问题，AI 时代人人都可以尝试写代码。但问题是，BA 在写代码的同时，并没有获得与之匹配的工程能力。他能用 AI 生成一段能跑的代码，但他不知道这段代码应该放在哪里、怎么和别人的代码共存、出了问题怎么回溯。工具给了他生产代码的能力，但没有给他管理代码的能力。
第三，也是最耐人寻味的一点——**发帖的人自己也不知道真正的问题在哪里**。他把一个工程基础问题，包装成了一个需要"AI Coding 专家"才能解决的高端需求。这说明，不只是 BA，连这个项目的管理者，对软件工程的认知也还停留在"代码能跑就行"的阶段。
这条帖子，浓缩了这个时代一种非常普遍的幻觉。
**AI 让写代码这件事，变得像发微信一样简单。**
你用自然语言描述你想要什么，它给你一段代码。你复制，粘贴，运行，成功。这种体验是真实的，这种能力的降低门槛也是真实的。我不否认这是一场革命。
但革命带来了一个副作用：**它让很多人误以为，会用 AI 写代码，就等于懂软件工程。**
这个误解，代价非常昂贵。我见过用 AI 三天搭出来的系统，上线第一周就因为并发问题彻底崩溃。我见过前后端两个人各自用 AI 写了一个月，最后发现接口完全对不上，返工成本比从头写还高。我见过创业者兴冲冲地拿着 AI 生成的代码找投资人演示，被一个懂技术的 VC 问了三个问题，当场哑口无言。
这些人都不笨。他们只是把"Coding"当成了"Engineering"。
**Coding 是写出能跑的代码。**
**Engineering 是让代码在真实世界里，长期、稳定、可协作地解决问题。**
这两件事之间的距离，比大多数人想象的要远得多。
写代码，是工程的起点，不是终点。在它之后，还有版本管理、架构设计、接口约定、性能调优、故障处理、团队协作、技术债偿还……这些东西，AI 帮不了你，或者说，AI 帮不了一个不懂这些是什么的人。
就像计算器的出现，让人人都能做复杂运算，但没有让人人都成为数学家。AI 的出现，让人人都能写代码，但没有让人人都成为工程师。
这本书不是一本技术教程。我不会教你怎么写代码，也不会教你怎么用 AI。
这本书想做的事情，是帮你看清楚一件事：**在 AI 把 Coding 这件事变得无比简单之后，真正的软件工程能力，到底是什么？它为什么重要？它藏在哪里？**
这本书写给三种人。
第一种，是正在用 AI 写代码、但隐约感觉哪里不对劲的人。你能感受到自己生产代码的速度越来越快，但同时也感受到代码越来越难以控制。这本书会帮你看清楚，那种不对劲的感觉，究竟来自哪里。
第二种，是管理技术团队、但自己不写代码的产品经理、创业者、BA。你们正在做一件非常冒险的事：用你们并不完全理解的工具，去构建你们并不完全理解的系统。这本书会帮你建立最基本的工程素养，让你知道什么时候该信任 AI，什么时候该停下来找一个真正的工程师。
第三种，是真正的软件工程师。你们可能正在经历一种奇怪的身份焦虑——AI 能做你曾经做的很多事情了，你的价值在哪里？这本书会帮你重新看清楚，工程师真正不可替代的东西是什么。
回到那条招聘帖。那个项目最后需要的，不是什么"AI Coding 专家"。它需要的是一个花半天时间帮团队建好 Git 工作流、定好前后端接口规范、告诉大家"以后代码这样管理"的人。
这些事情，一个有经验的工程师做起来，甚至算不上挑战。但对一个只会用 AI 写代码、从来没有经历过真实工程协作的人来说，这些东西是盲区。而盲区，往往是最贵的东西。
**人人都是程序员。但工程还是需要工程师。**
***
1. BA[^1]。Business Analyst，业务分析师。
[^1]: Business Analyst
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://mashihua.gitbook.io/everyone_is_a_programmer/qian-yan-yi-ge-zhao-pin-tie-yin-fa-de-si-kao.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.