是的，我们所有人都在撒谎。而且你大概也不例外。让我来证明一下。

最近我在读一篇英文文章，标题很扎心：「Every Developer Is Lying About Something — And AI Won't Fix It」。作者是 Dev.to 上的一位波兰开发者 Sylwia，讲的是技术圈里那些大家心照不宣的"谎言"。

读完之后我想了很久。这篇文章不是讲技术的，是讲人的。而恰恰是这种话题，比任何框架对比都更值得写一写。

因为技术你可以学，但人的问题，十年之后可能还在那里。

那些我们不敢问的问题

我认识一个真正的顶尖工程师。

他是那种让猎头抢着打电话的人——优化 LLM 推理驱动，技术一路晋升，辞职时手里握着好几个 offer。放在现在的行情，这已经算稀有品种了。

但他跟我说了一件事，每次想起来都觉得很有意思：

每次加入一个新项目，他都会觉得自己像个傻子。

别人看起来都在忙：写代码、交付任务、在 Slack 上敲得噼里啪啦。而他坐在那里盯着代码仓库，心里想的是：

• 这代码到底在干什么？
• 我们在做的是正确的事吗？
• 为什么这里要这么设计？
• 为什么不那样做更好？

然后他开始问问题。

结果往往是——没人真正知道。

这让我想起一个老笑话：

砍木头的工人们埋头苦干，领队爬上最高的树看了一眼，喊到：
"兄弟们！我们砍错森林了！"
底下的人回："管他呢，进度很好啊！"

这不是代码问题，这是人的问题。而任何 LLM 都救不了你——如果你从来不问正确的问题。

谎言一："我能搞定"——这句承诺有多真

刚入行的时候，我经常遇到这种情况。

TL 丢过来一个任务，看了一眼，心里想的是"这玩意儿我没做过啊"。但嘴上说的是："没问题，我来看看。"

实际上呢？我在赌。赌我能百度出来，赌我能 stackoverflow 出来，赌我看两篇博客就能假装懂这个框架。

有时候赌赢了。

更多时候——浪费了大量时间，最后还是不得不问同事。但那时候已经太晚了，要不就是代码写得面目全非，要不就是耽误了工期。

为什么不早点问？

因为怕。怕显得自己不行。怕 TL 觉得"这人怎么连这个都不会"。怕在团队里丢脸。

这是最常见的谎言，而且它会把一个本来可以快速解决的小问题，变成一场漫长的灾难。

我自己就犯过这个错。

当年第一次接触消息队列，TL 丢给我一个"简单"的需求：接一个 Kafka consumer。我嘴上说好，心里完全没底。然后我花了三周时间——不是夸张，真的三周——才把那个 consumer 调通。

那三周里我做了什么事呢？

• 看了十几篇 Kafka 入门博客，越看越懵
• 抄了三个不同版本的代码，都跑不起来
• 在群里问了一个"很蠢"的问题，结果发现文档里写得清清楚楚
• 最后一天半夜三点对着屏幕发呆，差点哭出来

如果我第一天就问："这个 Kafka 我没用过，能不能给我半小时了解一下？"——可能两天就搞完了。

但我没有。我选择了撒谎。

现在回头看，那三周浪费的时间，够我学两遍 Kafka 了。

谎言二："我有时间"——这句话是最贵的谎

这条开始涉及 senior 和 lead 的领地了。

有些人把"救火队员"当成自我价值的一部分——"这个系统离不开我"。有些人只是害怕承认自己已经超载了，害怕失去影响力。

所以他们继续接：

• 最难的任务
• 无尽的会议
• 需求评审
• 工时估算
• 和业务方吵架
• Code Review
• 架构决策
• 文档

说实话，总有什么会崩的。

我见过一个架构师，连续半年每天工作到凌晨两点。他不是在写代码，他在开会——晨会、需求会、设计评审、retro、一对一等。他的日程表排得密密麻麻，从早上九点到晚上十点，中间只有半小时吃饭。

结果呢？

• 他开始忘记说过的话，同一个决策要讨论两遍
• 他的 Code Review 越来越敷衍，只看个大概就 approve
• 最重要的架构设计文档，他写了一半就丢在那里
• 最后他请了半个月假，回来发现项目反而推进得更快了——因为其他人被迫学会自己做决策

人不是钢铁，没人能 100% 输出跑一辈子。

但很多人不愿意承认这一点，尤其在晋升压力下，"我还能扛"变成了一种勋章。

不只是 senior 有这个问题。我见过刚入职的应届生，不好意思拒绝额外的任务，觉得拒绝就是能力不行。结果第一个月就累到发烧，给自己埋下了burnout 的种子。

"我有时间"这句话最可怕的地方在于，说久了，你自己都信了。

谎言三："这个需求三天能做完"——你认真的吗

我在不止一个团队见过这种场景。

规划会上，某位同学举手："这个功能，我估计三天够了。"

TL 问："你确定？"
"确定。"

然后你发现——他估的是理想情况：不被中断、不开会、代码一次跑通、没有边界 case、没有甲方临时改需求、没有联调问题。

然后冲刺结束的时候，所有人都很惊讶：为什么没做完？

但这还不是估算最有趣的地方。

我遇到过更离谱的。

有个 senior 开发，估任务的时候像在守护什么神圣不可侵犯的东西。他会激烈地为自己的数字辩护："这个任务确实很复杂！"团队其他人心里都清楚没那么夸张，但为了早点结束评审会，选择举手投降。

然后呢？至少三次，他自己把那个"超复杂"的任务捡起来——一小时就写完了。

也就是说，那场估算讨论花的时间比实际开发还长。

这种人你身边有吗？我猜肯定有。

估算本身不是问题，问题是——为什么一个人会系统性地高估或低估？

有些是能力问题，他真的不知道这个任务需要做什么。有些是心理问题，他需要显得"工作量饱和"。还有些是文化问题，团队不允许说"我不知道"。

不管是哪种，最后伤害的都是项目。

谎言四："这个技术栈是最好的，其他都是垃圾"

这种人是危险的。

他们说话的方式是这样的：

"用这个技术，而且只能用这个技术，因为其他都是垃圾。"

你可以填入任何技术圣战：

• React vs Vue vs Angular
• Java vs Go vs Rust
• 微服务 vs 单体
• Postgres vs MySQL vs MongoDB

我写过「我喜欢 Tailwind，对不起」这样的文章，但即使是那篇，我也专门讲了它的缺点和使用场景。如果有一天我开始宣称某技术对所有情况都是最优解，请一定在评论区告诉我：

"去楼下草地走走清醒一下。"

我一直在想这种绝对自信是哪来的。并不是所有人都是付费 KOL，有些人是真情实感地卷入了技术圣战。有些人可能只是对自己会的技术有感情——因为他们只懂这个。

这种确定感会杀人。

项目里大家停止质疑决策，其他人不敢发声，业务方默认"那个说话很自信的人肯定是对的"。

我见过一个团队，因为 tech lead 坚持要用某种"最先进"的框架，结果项目延期了三个月。那个框架确实在某些场景下很强，但不适合他们的业务类型。后来新来的 CTO 在 retro 上说了一句话很到位：

"不是框架的问题，是决策过程的问题。没有人敢说'我们可能选错了'。"

最好的情况：你身边多了一个懂框架但不懂业务的人。

最坏的情况：你最终用了一套烂架构，全靠 egos 在那里撑着。

谎言五："我已经测过了"——这个谎的代价

这条可能是我见过最普遍的。

Code Review 里，你看到 PR 状态是 "Changes requested"，然后你去问作者，他说："啊，我改了，但还没 push。"

或者："我本地测过了，没问题。"

然后你一跑，crash 了。

或者更常见的——"这段代码我没动过，之前就有问题"。

你自己信吗？你以为别人看不出来吗？

我见过一个项目，交付前一周发现一个严重的 bug，追溯到两个月前的一段代码。那段代码的提交记录写着 "fix: quick patch"。两个 senior developer 都在那段代码上 review 过，没有人提出问题。

为什么？

因为没有人真的去理解那段代码。他们 trust 了提交者的人品，trust 了同事的技术水平，trust 了过去的历史记录。

但代码不会因为你信任它就变得正确。

还有一种更隐蔽的撒谎：我看到过有人把测试覆盖率当作 KPI，然后疯狂写那种"assert true"的测试来刷数字。那也叫"测过了"，但跟没测有什么区别？

AI 为什么也救不了你

这是文章最核心的观点，也是我想重点说的。

现在所有人都在说 AI、聊 AI，好像它是来解决一切问题的银弹。但现实是——

有多少 AI 工具救过那个不敢问问题的 junior？

很少。

Coding Agent 确实能帮你写代码，但它救不了一个不敢承认自己不懂的人。他会把错误的 prompt 喂给 Agent，然后得到一堆看起来像模像样的垃圾代码，最后提交到仓库里——因为他甚至不知道代码是对的还是错的。

我用过 Claude Code，用过 Cursor，用过各种 AI 辅助工具。我发现一件事：AI 工具的效率取决于使用者的水平。

同一个 AI 工具，在不同的人手里，产出差距可以是十倍。

经验丰富的工程师知道问什么 prompt，知道怎么验证 AI 的输出，知道什么时候 AI 在胡说八道。而新手呢？AI 说啥他信啥，然后花三小时 debug 一个根本不存在的"bug"。

这不是 AI 的问题，这是人的问题。

有多少 AI 工具救过那个超载的 senior？

更少。

AI 可以写代码，但它不能帮你开会、帮你做决策、帮你做 Code Review。你把任务丢给 AI，你还是得等它返回，然后 review，然后改 bug，然后集成——你还是在做所有的事情，只是多了一个环节。

研究甚至表明，在某些场景下，AI 工具反而拖慢了开发者。因为 prompting 和 review AI 输出本身也需要时间和精力。

我看到过一些团队，引入 AI 工具之后反而更忙了——因为要花时间 review AI 的输出，因为 AI 生成的代码有时候比手工写的还难维护，因为要不断调整 prompt 来让输出更接近需求。

这不是 AI 的错。AI 是工具，工具不会自动解决问题。解决问题的是人。

真正的问题从来不是代码本身。真正的问题是写代码的人。

怎么破？几点真实的建议

说了一堆问题，该说说解法了。

虽然我说没有"神奇解决方案"，但有些事情确实是有用的。

第一，敢说"我不知道"

这是最难的一步，也是最重要的一步。

我现在的团队有一个规矩：新人不允许说"我试试看"。他必须先说他懂不懂、要学多久、卡在哪里。这个规矩一开始让我很不舒服——谁愿意承认自己是新手呢？

但效果是明显的。我们发现早期沟通成本大幅下降，很多原本要在 Code Review 时才暴露的问题，在设计评审阶段就被抓出来了。

我最近在学一门新的框架，前两周我几乎每天都在群里问"这个概念我没听懂，谁能解释一下"。一开始我觉得很丢脸，后来发现——大家其实都很忙，没人记得你问过什么问题。而那些问题，恰恰是帮助我快速上手的关键。

第二，把"不估理想情况"变成团队文化

我们现在的估算方法是：先估"最快情况"，然后乘以 2，再加一天缓冲。这个数字听起来很夸张对吧？但它往往还是偏保守的。

为什么要乘 2？因为我们需要接受中断、接受调试时间、接受突如其来的联调问题。

这不是悲观，这是现实主义。

我们还有一个规矩：每个任务估完之后，必须说清楚"最大的不确定因素是什么"。这让估算从"掷骰子"变成了"风险管理"。

第三，给自己和同事留"不懂"的余地

我见过最好的 team 氛围，是大家可以公开说"这个东西我没用过"。

没有人在意你懂多少，每个人都在意你愿不愿意学。

一个团队里最危险的人，不是那个技术不行的人，而是那个技术还行但装成什么都懂的人。后者会浪费你更多时间。

我们团队最近在推行一个"不懂就问"的活动：每周五下午有一个小时的 open Q&A，任何人都可以问任何问题，不管多简单。我们发现很多长期困扰大家的问题，其实一句话就能解决，只是之前没人敢问。

第四，正视"时间不够"这个问题

如果你发现自己连续两周都在加班，第一件事不是继续扛，而是跟你的 manager 谈。

谈什么？不是"我需要更多时间"，而是"这些任务里，哪些是可以不做的，哪些是可以延后的，哪些是可以别人帮忙的"。

很多时候，manager 并不是故意给你压任务，他只是不知道你已经超载了。你不说，他以为你还能扛。

诚实一点，其实没那么可怕

我不是什么完人。

这些谎我也撒过。而且不只是对别人——有时候是对自己。

我曾经在一段低谷期，每天假装一切正常，实际上早上起床要深呼吸三次才能打开电脑。我告诉自己："大家都在努力，你凭什么不行？"

后来我看到一个研究说，程序员的精神健康问题被严重低估了。很大一部分原因是我们不愿意示弱——这个行业的文化就是这样，你不能说不。

但问题是：你越是假装，你越是做不到。然后你更焦虑。然后你更假装。

死循环。

软件工程里的大量问题其实根本不是技术问题。它们是人的问题：

• ego
• 不安全感
• 害怕显得蠢
• 害怕承认错误
• 害怕说"我不知道"

敢于说"我不知道"，敢于在规划时公开讨论不确定性，敢于说"不好意思，我还没理解，能再解释一遍吗"——这不会让别人看低你。

很多情况下，恰恰相反。

团队沟通变好了。其他同事也开始问问题了。对话变得更诚实了。问题被更早地发现。

试试看。就一次。你可能会惊讶。

写在最后

文章结尾作者问："你在团队里见过哪些开发者的谎言？"

我想把这个问题抛给你。

你身边最常见的谎言是哪一种？是你自己撒过，还是见过别人撒的？后来怎么解决的？

以及——你现在有没有在撒某个谎？

如果有，想想这篇文章。想完了，点个赞，然后去跟你的 TL 或者同事说一句：

"其实这个东西我还不太懂，能教教我吗？"

相信我，没那么可怕。

本文灵感来源：Dev.to 作者 sylwia-lask 的文章「Every Developer Is Lying About Something — And AI Won't Fix It」