前述
过去的几个月，我一直在涛思数据内部推动 AI 提效赋能，而且对大家使用Token 数目不做任何限制。自己更是身体力行，用 AI 重写用户手册、构建端到端测试例、拿出 AI-Agent Ready 的架构设计方案，做研发质量以及开发量的评估等等，把大家的积极性充分调动起来，让每个人看到 AI 的效果。但发现大家有个共同的焦虑：AI 会不会抢走我的工作？
这个问题在各种技术论坛、程序员社群里反复出现，有人悲观，有人乐观，也有人干脆选择不去想。我的答案是：程序员不会消失，但"只会写代码的程序员"会非常危险。过去几十年，程序员的核心价值是"写代码"——你学会了某门语言、某个框架，你就能把需求转化为代码，因为这些工作有一定的门槛，这成为你不可替代的竞争力所在。但现在，这件事 AI 正在越做越好，而且速度快得让人难以相信。
我认为真正的问题不在于 AI 会不会写代码，而在于我们正在从"程序员写代码"转向"程序员管理 AI 写代码"，这是一次真实的职业迁移，和以前每一次工具革命一样，会淘汰一批人，也会造就一批新的高手。
我是1984年高中一年级的时候开始写程序的，当时是在Laser 310 上写 Basic, 之后就几乎没有中断过写程序。2016年底，我花了2个月的时间，写了1.8万行 C 语言程序，开发出时序数据库 TDengine TSDB的第一版，是真正的程序员老炮。最近两个月使用 Claude Code 做开发的经验，更让我有了第一手非常直接的感受，写出来与大家分享。
过去几周，我做了什么
我用 Claude Code 做的不是玩具项目，而是涛思数据真实的产品研发工作。TDengine IDMP 涛思数据最新发布的产品，是AI原生的工业数据管理平台。它的文档量很大，超过1000页。过去这种工作需要我以及研发团队花大量时间，反复对齐，效率极低。现在我把产品的定位、功能描述、目标用户的使用场景一一交代清楚，而且让Claude Code 直接用浏览器插件来模拟人体验产品，让 Claude Code 来写，我来审核、调整、把关。不仅效率提高了百倍，而且质量更好 -- 因为 AI 不会嫌累，不会遗漏，不会因为"这功能大家都懂"就跳过某个关键步骤，而且用词、跳转链接一定不会错。
测试是研发团队永远欠的债。我把用户使用场景逐一描述清楚，让 Claude Code 生成e2e 的 Playright 自动化测试脚本，然后逐一验证、补充边界条件。以前需要一两个测试工程师花一周的工作，现在一天之内可以有大量可运行的测试例框架。尤其是对于标准的CRUD操作，一句提示词就解决，比如“请帮我在IDMP里创建一个元素、修改它，搜索它，然后删除它”，它几分钟就全部搞定。
在架构设计上，IDMP 的下一步要让它成为AI Agent最友好的软件。因为在我的眼里，AI时代，工业数据底座这类基础设施软件，用户不会是人，而是AI，因此我们必须做好 AI 体验，对其接口需要改造甚至重构。这涉及数据目录、上下文传递、工具调用链等很多细节。我把对业务场景的理解、对技术约束的判断、源代码目录等一条条告诉 Claude Code，和它来回讨论，最终形成了一份比我单独思考质量高得多的设计文档。
此外，作为还冲在产品第一线的公司创始人，我还让 Claude Code 分析研发同学的 PR 记录 -- 提交频率、代码变化量、涉及模块、注释质量 -- 然后给我一个结构化的摘要，包括工作量以及质量的评估。这不是要取代 Code Review，取代各个团队负责人，而是让我能在 10 分钟内对整个公司的研发状态基于实际的代码有一个清晰的全局视角，而不是靠开会、靠问人。
我有空的时候，还 Review 了公司同事写的很多 SKILL, 指出了不少问题，把输出结果的质量大幅提升的同时，还把消耗的 token 数大幅降低。大家犯的最大错误就是把一些确定性的任务也让 AI 去倒腾。
为什么我做得比一般程序员好
说这句话不是自夸，而是因为这背后有一个值得认真思考的规律。AI 工具人人都能用，但用出来的效果差距极大。
我观察到，那些用 AI 用得好的人，有一个共同特点：他们懂得分解问题，懂得提出具体的问题。分解问题，是说你要把一个大的模糊需求，拆成若干个有明确边界、有具体输入输出的子任务。"帮我写个用户手册"这种需求，AI 给你的东西一定很烂。但如果你告诉它"这是一个面向工业现场工程师的功能，他们不懂 SQL，不懂流计算，主要使用场景是查看各类设备的运行状态、历史变化趋势，配置KPI计算指标和报警规则，对批次或事件进行分析以优化生产工艺和流程，找到事故根因，请登录 idmp.taosdata.com 对各种功能进行体验，以步骤化的操作指南形式来写，语气要简洁直接"，结果就会好非常多。
提出具体的问题，是说你要把自己的知识结构、判断依据、约束条件都清晰地传递给 AI。这要求你对业务、对技术、对用户都有深刻的理解。你理解得越深，AI 才能帮你越好。AI 放大的是你已有的能力，而不是替代你没有的能力。 这也是为什么我 -- 一个有 42 年编程经验、三次创业、深度理解物联网、工业互联网数据处理难题的老程序员 -- 用 AI 能做出比很多年轻程序员更好的结果。不是因为我比他们更会用工具，而是因为我更清楚地知道自己要什么。
"只会写代码"为什么危险
我说"只会写代码的程序员"危险，不是在贬低写代码这件事。代码是工程师的基本功，我自己到今天都能随手写 C 语言程序，而且以后还会继续写。我说的是，如果一个程序员除了"把需求翻译成代码"之外，没有其他能力积累，那他的处境会越来越难，因为这件事正是 AI 最擅长、而且进步最快的部分。我面试研发时，经常让候选人当场写 Consumer-Producer 程序，如果现场能随手写出来，我是一定录用的。但现在根本不需要了，因为 AI 几秒钟就帮你生成出来。
但有几类能力，AI 目前远远做不到，而且短期内也做不到。
对业务本质的理解：我去了解卷烟厂为什么在意某个质量指标，去搞清楚油田的数据采集逻辑，去搞清楚大型设备预测性维护后的机理模型，这些需要和人交流、需要在现场、需要跨越领域壁垒，AI 读的是已经存在的文本，但业务洞察来自于那些还没有被写下来的经验。
定义问题、分解问题的能力：AI 是一个极其强大的执行者，但它不知道应该执行什么，问题的定义、任务的分解、优先级的判断，这些是工程师真正的核心价值。
审美和判断力：一个好的产品，不只是功能正确，它还需要有结构清晰的文档、直觉友好的交互、优雅一致的设计语言，这种判断力来自于长期的积累和品位的培养，AI 给你的是"能用"，但"好用"需要人来把关。
程序员的未来
我不是未来预测大师，更不是职业发展导师，我只想从一个老炮程序员角度，从一个技术公司的创始人角度说一件事：从现在开始，把 AI 当成你最重要的下属和搭档来管理。你要给它清晰的目标，要拆解任务给它，要检查它的输出，要在它跑偏的时候纠正它，要在它给出意外好答案的时候反思为什么好。这个过程，就是在训练你作为"工程师管理 AI"的能力。
会用 AI 的程序员和不会用的，三年后的差距，会比会写代码和不会写代码的差距大的多。
我 57 岁，用 Claude Code 做产品研发，做得乐此不疲。不是因为它让我偷懒，而是因为它让我能把自己几十年积累的经验，以从未有过的效率转化为真实的产出。在我的眼里，AI 不是威胁，而是我的机会，也是所有程序员的机会。能不能抓住，取决于你愿不愿意改变自己对"程序员"这个职业的定义，进行一次职业迁移。
后述
此文来自涛思数据创始人CEO -- 陶建辉 分享于 2026年4月9日
