“我以为掌握这些领域知识，能让我在只会写代码的程序员里脱颖而出，但现在，现实已经不是这样了。”发帖人写下这句话时，他刚经历了一轮认知冲击——自己深耕多年的财会领域经验，在大语言模型面前，正迅速变得可以随时被“询问”出来。
事情的起点是一篇帖子。作者在技术社区贴出《大模型正在侵蚀我的职业生涯》后，文章意外走红。随之涌来的大量评论，让逐个回复变得不现实，“我不想在 Hacker News 或 Reddit 上陷入无尽的讨论，那会消耗我的理智。”于是他决定挑选一些典型声音，在自己的博客里集中回应。
最先被拎出来的是质疑：“我一整天都在调试大模型，但绝不会同意去主导一个金融产品。”这条评论背后，是人们对大模型处理本地税务法规等细粒度业务的普遍不信任。博主承认，自己一开始没说明白：大模型的确无法自动化处理本地税法这类极细的问题，可这部分工作，本身是由公司的法务团队负责的，“而法务团队，现在也在用大模型自动化大量日常工作。”
让他难过的，是那些曾经认为能构筑职业壁垒的领域知识，比如会计流程中的某些细节、分类账实现的特殊处理。过去，这些知识让他觉得“会写代码的人很多，懂这些业务的人很少”。但现在，只需打开 ChatGPT Pro 或 Extended Thinking，直接用自然语言提问就能得到答案。他感慨，那种通过掌握领域经验来区别于普通程序员的想法，在如今的模型能力面前已经立不住了。
连过去对这类业务一头雾水的AI智能体，也因为三个变化变得能打了：更新的模型、面向智能体友好的文档，以及团队专门编写的一份 AGENT.md 文件——核心手段就是“求智能体在写代码前，先把该死的文档读完”。作者发现，自己需要向资深同事请教的情况越来越少，需要人类输入才能推进工作的时刻急剧萎缩，“停下来想了想，这真的挺吓人。”
还有一条评论直指公司管理的轻率态度：“一家金融科技公司，管理者竟然推荐用AI来加速设计文档，这听上去对资金安全太过草率了。”博主承认自己也不认同这种做法，但他有自己的应对办法，而且不止一个。
第一个办法是，在编写设计文档时，刻意把实现细节、状态机等内容写得相对抽象，留给后面深思熟虑的实现空间。自从引进AI、随后又经历裁员，团队里每个人都淹没在数不清的文档和评审请求里，评审者变得远没有以前那么“挑剔”，这反而给了他绕过文档最初缺陷的余地。另一个办法是，在团队看板上做文章，为自己争取时间。他总是额外往迭代里加上端到端测试的卡片，借由测试找到bug，就有理由在功能正式上线前，提交一系列修复或改进卡。这样既争取了更充裕的实现和复查时间，也能在敏感环节——比如那些最核心的初始实现部分——多拆几张卡，用更小步快跑的方式谨慎推进。
“我喜欢这么做吗？当然不，可我又有什么选择？”他得到的反馈显示，自己所在的公司还不算“氛围式编程”最极端的地方，贸然跳槽可能落入更差的环境。至少眼前这个地方，他知道怎么安抚利益相关方那被AI拉高了的期待值，靠一点工作流上的“杂耍”，维持住自己对代码质量的最后一道防线。
热门跟贴