2026-08-29 08:00:00

这一年多的时间以来，AI Coding 已经从一个新潮的编程方式变成了默认方式，每个人都用着近乎相似的模型，相似的设备，相似的 Agent，理论上所有人产出的代码水平也应该相似，但如果你在一线工作过，你会发现实际情况恰恰相反，大家的代码产出水平方差反而比以往更大。这是一个相当有意思的话题，但是我却发现在互联网上鲜有人讨论。

为什么大家明明用着一样的编程方法，但是产出质量却会有如此大的差异？特别是当我反思自己每天跟 AI 的对话的时候，我觉得没有任何技术含量，我既没有什么魔法的提示词，也没有装什么花里胡哨的 Skills，纯粹就是把 AI 当作一个伙伴一起协作完成工作。我认为每个人的工作方式也都是如此，但是为什么还会存在个体差异？

在研究这个问题许久后，我认为我找到了一个很少有人讨论，但是在我看来是 AI Coding 核心要义的工作方法，我把它叫做「尽职编程」，用更口语化的表述就是「得靠谱」。

如果你和 HR，物业，政府机关等社会人员打交道多了，你就会知道在这个社会，要求这些行政人员帮你办成一件事有多难。但是我相信每个人的社交圈都会存在一种特能帮你办成事的能人，在古代，他们有另一种名字，叫做乡绅或者师爷，他们的工作就是两个字「办事」。需要注意的是，这类人自己往往并没有具体的专业知识，事情也多半不是他们自己执行的，但是他们就是有能力让别人高高兴兴把事情办成了。

在我看来，AI Coding 需要的就是这种能力。这个时代由于编程的速度极大地提升，工作分配的颗粒度也大大加粗，上一个时代每个人分到的活可能只是写某个模块甚至是某个函数，你不需要关心最后大家工作内容合并做成的事情是什么。但是如今更多时候是要让你把某件事情做成。而做成一件事情可能分一百个子事情，AI 有能力做完每件子事情，但是 AI 没有能力决定要做哪一百件子事情，这个的上下文可能在老板与你的沟通中，也可能存在你历史积累的工作经验里，还可能是你生活的常识，甚至还可能要预测未来的发展。而 AI 完全没办法通过你聊天窗口那几句话知道这么多上下文信息。

我在上一家公司接触过一种我觉得最可怕的人，甚至我都一度想申请让公司禁止他写代码，那就是他会让 AI 来决定，做成某件事情，需要做哪一百件事情，然后让 AI 全完成了。这就引出了今天的主题，那就是「尽职编程」。在我看来，他最大的错误就是没有做到「尽职」。坦率讲，AI 在自主决策的时候，正确率其实也不低，但绝对没有达到 100% 的地步。你和 AI 说要写一个文章编辑功能，如果不提供其他信息，AI 会自己决策是实时保存还是点击按钮保存，编辑框是固定大小还是会随着内容变长。但是 AI 依然会漏掉一些细节，比如多人同时编辑会如何。因为你给他的提示词就几个字符，他只会把它当简单的需求完成，况且如果 AI 思考过多可能还有过度设计的嫌疑。这时候，非常依赖人在其中多思考，多反问 AI，更重要的是，虽然代码不是你写的，但是你要能够回答得出在技术评审的时候别人的提出 —— 这是我认为的达到了「尽职编程」的标准。

如果只是为了实现需求，我甚至感觉在 AI Coding 时代到来后，我每天只需要工作 2 小时。但我其他时间其实往往是花在了「理解 AI 的设计」上。我会通过让 AI 画架构图，设计文档的方式，来理解 AI 写出来的代码而不是阅读代码本身，我甚至有一个百试不爽的魔法提示词是让 AI 写一个「面向产品经理」的文档，这样甚至连枯燥的技术语言都不需要阅读就能理解 AI 的设计了，还能把这个文档丢给产品经理让其他人也能理解系统的实现。

但「尽职」是一个主观行为，且没有尽头。什么样的需求需要尽职到什么程度才够，这完全凭个人自己的理解。比如近期我写的一个用来评测 Agent 质量的系统， 我就没做太多「尽职」工作，因为他的代码并非核心代码，且极容易推翻重改。但如果你要写一个 Agent 的核心代码，尽职就没有止境了，它不仅仅在你提交代码之前要 review，每过一段时间，随着代码的持续演进，还需要反复对系统进行「回归尽职调查」，才能对系统有最新的认识。而这些工作内容，不会产出可看见的工作结果，做与不做，全凭个人，做了也不一定有立竿见影的效果，不见得每家公司都能容纳这种工作方式尤其是大公司那种不懂行的中层领导的团队里。

尽管如此，也还是有一些方法可以在 AI Coding 工作流里，注入一些客观工具，鼓励这种「尽职精神」在公司内开枝散叶。比如我最近在我们的主仓库加了一个 Codex 自动 Review 代码的插件。注意，这个不是网上那些浅显的看几行代码评价几个无关痛痒问题的那种插件。而是会把代码库 clone 下来，结合代码库看修改本身产生的所有副作用，然后再给出 review 意见。而它的 Agent 上下文，完全独立用户 AI Coding Agent 的上下文，所以它会评价的非常客观。如果你就是执意要在一个 Get 接口修改数据，Claude Code 会因为你的命令而偏袒让你这么干，Review 的 Agent 不知道你的固执，所以依然不会让你这么干。由于你每一次修改都会有 Review 意见产生，你就会被迫进行多轮修改，或者你要直说你不同意 Review 意见。而且 github 上能看得到你的「尽职」过程，review 你代码的人本质上也是在 review 你的尽职过程。这就把主观的决策变成了客观可见的努力。我的体验下来，这个 Review Agent 不知道是不是因为提示词的原因已经有点演化成 Review 喷子了，但是在这个每个人都被 AI 阿谀奉承的时代需要喷子。

2026-08-13 08:00:00

我在 AI Coding 能力达到生产级水平后，先后在一家世界500强大公司和一家创业公司任职，有意思的是，我个人对待 AI Coding 的态度和实践在这两家公司截然不同。

在大公司的时候，由于我们在负责一个直接和商品定价有关系的重要系统，且系统已经历经了十几年的持续迭代，所以我对我自己和同事提交的每一行代码都要求极高，不管这行代码是不是 AI 写的，写代码的人必须要看过且看懂了每一行代码在做什么。如果有一个家伙提交了一大片根本无法人工审查的代码，我会对这个家伙非常生气，并认为这是对这个系统和其他同事的不尊重。在这家公司，AI Coding 对整体工作效率的提升其实微乎其微，三分之一的时间在开会对齐对需求的理解，三分之一的时间在处理审批之类的各类杂活，剩下的三分之一时间也不在写代码而在验证代码，真正的写代码时间微乎其微。

然而后来我来到了一家创业公司，我自己变成了那个每天提交大量人力无法 review 的代码量改动的家伙，但于此同时我对改动的自信却不比之前在大公司谨小慎微的时候少。我会通过让 Agent 画流程图，写文档等多种方式帮助我去理解产出的代码，并以一目十行的速度大致检查下产出代码又没有特别让人意外的片段。

在大公司，个人对公司成长发挥的作用微乎其微，可以说基本为零。甚至个人对团队的贡献，有时候都是微不足道的。很多团队的存在意义，是维持这个系统的/正常运转，而不是创新。相反，如果你因为创新而引发了事故，那么你对团队的伤害往往远大于贡献。特别是现在 AI 放大了个人的能力，也放大了破坏力，一个不靠谱的人，现在要捅出超大篓子的可能性远大于以往，基于此，最适合团队正常发展的策略就是谨慎谨慎再谨慎，不然我很怀疑你作为团队负责人每天看着大伙儿的编程速度大跃迁能否晚上睡得着觉。

而在创业公司，每个人摊上的是大公司几个团队的活，如果不充分利用 AI 的 Coding 速度，根本不可能干完日常的工作。况且创业公司要么没赚钱要么赚的钱不多，而且创业公司的价值在于未来能赚多少钱而不是这个季度赚了多少钱，在这种情况下，走得快比走路姿势稳不稳重要的多。这也是我觉得现在在创业公司的编程体验远超大公司的一点。对于一份工作来说，我们当然要保证工作的完成质量，但因为大公司的代码量之大和审批流程之复杂，保证质量这件工作往往相当之无聊。如果环境允许你充分发挥自己的主观能动性，在质量与速度之间，发挥自己的审美和判断力来做取舍，这种工作的创造感其实远高于传统人工编码的时代，但也对实操人的素质提出了更高的要求。

2026-05-17 08:00:00

学习一个技术最好的方式就是能够写一片文章把这个技术的原理解释清楚，本文记录了我在阅读 《Build a Large Language Model (From Scratch)》一书以及和 Claude Code 对话过程中的笔记，仅供参考。

术语解释

向量点积

定义：向量点积为标量

a = (a1, a2, a3)
b = (b1, b2, b3)

a · b = a1*b1 + a2*b2 + a3*b3

几何意义：

a · b = |a| |b| cos(theta)

其中 theta 是两个向量的夹角。

用途：衡量向量相似度

矩阵转置

符号表示：Kᵀ

定义：

A =
1 2 3
4 5 6

Aᵀ =
1 4
2 5
3 6

线性层

假设某个词的向量是 2 个数字：x = [2, 5]。我要 3 个输出，就准备 3 个配方（权重和偏置都是训练学出来的数字）：

2026-03-30 08:00:00

最近在做一个思想实验，如果你面前有一个按钮，按下就可以让 AI 从世界上消失，你是否会按下。身边很多朋友的答案都是会毫不犹豫的按下，即便有一些人还是那种最拥抱 AI 的人。

拥抱 AI 和厌恶 AI 可以同时在一个人身上发生，我自己就是这样的人。我厌恶 AI，是因为对昨日世界的怀念，我拥抱 AI，是因为今日世界无法回退，我没有不拥抱的选择。

现在的 AI 虽然可以代替我完成很多事情，但是在事情完成后，带给我的并不是成就感而是一种无尽的空虚。有了一个 idea，找一个趁手的模型，用几句提示词让 AI 吭哧吭哧干活，再做几轮调整，最后几个小时项目完成了，剩下一段贤者时间，你不知道这个项目数据库的 schema，也不确定架构是否能支撑多少的用户规模，未来有新的需求，你只能对着这个黑盒许愿，在许愿前完全没有关于需求可行性的任何概念。当 AI 给你完成了修改后，你不知道会不会损坏已有的用户的数据，只能按照 AI 的要求上线。一通操作下来，身体很累，精神很空虚，干了一天的活，又好像什么也没干。伫立在这个黑盒面前，反反复复操作几个月，不知道自己究竟学到了什么。AI 有了更多的数据，一天天变得更聪明，而我们自己呢？

在昨日的世界，虽然我们工作很累，但是工作结束会有一种智力的满足。当其他人来咨询某个需求是否可行，我们可以给出斩钉截铁的答案。当需求可行的时候，我们知道需要修改哪些地方让它可行，当需求不可行的时候，我们知道因为哪些原因所以它不可行。我们面对的是一个充满确定性的世界，我们确定昨天的工作，确定明天的工作，确定自己的职业生涯，确定未来能够有一份收入养家糊口生儿育女。今日的世界一切都不确定，不确定昨天做了什么，不确定明天会做什么，不确定这每天光聊天的工作能否有职业生涯，不确定未来什么样的人才可能凌驾于 AI 之上能有一份糊口的工作。

今日的世界互联网的整体审美也在逐渐倒退。互联网到处充斥着用 AI 生成的机械感十足的图片，也没人在乎是否是真的符合自己脑海中想象的模样，只要和提示词差不多能用即可。各种「高效率人士」用 AI 创作着各种垃圾的文章，宣扬自己最高效的工作流，攀比着各自的 token 消耗量和同时并行启动的 Agent 数量。每天都把一些简单的步骤封装出各种下一个月就会消失的名词概念，并以自己掌握的名词数量而沾沾自喜。

我时常在刷新推特时间线的时候，感受到自己是在一群推土机中漫步，页面滚动，一颗颗大树被连根拔起，群众在欢呼，木匠们做出一件件精美的家具。而我只想回到自己的瓦尔登湖旁边，但是小木屋也早已被掀翻，地上留着一张告示，顺之者昌逆之者亡。

2026-03-05 08:00:00

上周末用 AI 写了一个新的产品： Magic Brush。

这个产品的 idea 来自于我经常用 AI vibe coding 一些小的前端产品，但是如果每次都为这些小产品创建独立的域名和部署太过于繁琐，而且目前也缺乏一个聚合站点可以浏览其他人创建的小产品。另外，我在写博客的时候，也经常会想要插入一些交互页面来展示我的 idea，但是如果要在博客里插入一堆 js/css 代码又会导致博客无法长期维护。我把这些需求收集了下，整理并抽象出了一个产品形态：

这个产品可以允许用户使用自然语言创作页面，然后通过 iframe 嵌入到任意网页中去。并且这个产品还可以有一个广场功能，可以看到其他人的作品。不仅仅能用来做博客的交互页面插入，也可以作为产品原型设计的工具。

产品设计

Magic Brush 由 2 主要页面组成。

页面设计页

用户可以在设计页右边会话框写自己的提示词与 AI 交互，左边的页面会实时渲染最新的页面。其他用户可以以只读的方式访问该页面，并且也能看到提示词，方便其他人模仿修改并创建自己的页面。

广场页

广场页面允许看到所有 Public 的页面设计，可以以 Like 数量排序或者时间排序：

Use Cases

创作可交互文章

对于有些文章来说，文字并不是最适宜的表达载体，例如游记。你可以把你的游记喂给 AI 生成可交互的页面，然后再插入到文章中。例如我的 «熊野古道中边路纪行» 游记中，可以被转变为：

创作流程图

传统流程图需要用截图的形式插入到文章，导致不易修改。我们可以让 AI 生成流程图页面，然后直接插入到文章中，并且后续实时渲染最新的修改。

创作自定义工具

你还可以根据自己需要，写一个自己用的趁手的前端工具，例如：

甚至能在网页上插入一个小型浏览器:

这些工具都能用 https://brush-api.elsetech.app/pages/cJ3w_m4e3K 的方式作为工具本身全屏打开。

实现过程

Magic Brush 的实现非常简单优雅，整个 Design Agent 在前端运行，后端代码无法拿到用户的 API Token。后端部署在 Cloudflare Worker 上，数据库使用 Cloudflare R2 。整个产品的维护成本接近于 0，除非用户变多。

Design Agent 的设计与传统 Code Agent 类似，约束是产出只能是一个 HTML 文件。在最开始的时候模型会返回一个根据初始提示词生成的 HTML 页面作为起始文件，而在后续 Modify 过程中，只允许调用一系列 tool call 来修改页面，最大化减少了 token 的消耗。

2026-02-26 08:00:00

说来惭愧，我已经好几个月没有完全手写代码了，甚至像是把某个变量改一个名字这种活我都宁愿输入更多字符告诉 AI 来做而不是自己直接改了，因为我知道，哪怕是变量重命名这种简单的活，AI 也能做的比我仔细，它会检查所有用到这个变量的代码、相关的注释以及单元测试，然后一并都修改了，而我自己其实历史上就犯过不少忘记修改关联地方的错误。

过去一两年的时间，AI Coding 引来了飞速的发展，就我的个人体验而言，大概经历了三个阶段。AI Coding 1.0 时代，AI 只是简单给你提供代码补全，代码总体还是人在写。而在 AI Coding 2.0 时代，人更像是在指导 AI 写代码，一次 prompt 只能高质量地写一百来行代码，你需要仔细检查代码是否符合你的需求。而最近两个月的时间，AI Coding 3.0 来到了一个奇点时刻，你甚至都不需要精心设计你的 prompt，只要简单描述下需求，AI 自己会根据代码上下文，以极高质量生成成千上万行代码，而人无论是体力还是智力已经无法 review AI 的代码，只能粗浅把握一个编程方向。在两个月之前，我或许还会认为过去的编程工作还能继续苟活一两年的时间，而现在我认为此刻所有传统的编程工作已经在事实上被淘汰，我们这些传统程序员之所以还没有被开除的原因仅仅只是公司自己在制度流程上还没有完全适应 AI 作为员工的方式，而这个适应过程可能会持续几年之久。

在完全不手写代码的这几个月里，我时常在 AI reasoning 的间隙问自己到底在做什么。我似乎做着完全没有技术含量的『传话』工作，但与此同时，如果真要把我淘汰直接让 PM 和 Agent 对话，似乎也很难实现他们的需求，而且出事的风险极高。这意味着我依然在提供自己的价值，只是这个价值无法再被很好的「可视化」。我之所以比 PM 能让 AI 更好地干活是因为我具备一些专有的知识，这些知识的产出可能仅仅只是一个 Yes 或 No，但这不影响他们的价值。我之所以会觉得浑身难受的原因还是之前的日子过得太苦，觉得必须一定要自己手动干很多活才能体现自己的价值，没有真正把自己从一个「劳动者」换位到「管理者」。一个好的管理者肯定不是办公室里最忙碌的那一个人，那些做出对公司最有价值决定的管理者最终的产出也无非就是一个 Yes 或 No。能力强的员工往往希望老板管理的越少越好，AI Agent 也是如此。

我们已经近乎实现了 Coding 的自动化，但是在一个公司里，Coding 只是整个公司工作的很小一部分，甚至都只是程序员工作的一小部分。我们现在拥有了一个无限智能的机器，但是整个公司运行制度都是面向人类设计的，Agent 需要发挥能力必须建立一个正向的 Loop，现在的 Loop 仅仅只建立在 Agent 内部，公司的每个环节与 Agent 并没有建立起这个 Loop，甚至连 Input/Output 渠道都没有建立。未来 Agent 会进一步渗透进整个公司一切流程的方方面面，不仅改变软件工程师的工作内容，也会改变产品经理，HR等一切职能的工作内容。我觉得这些传统工作岗位的消失会成为必然事件，但并不意味着不会创造新的工作岗位。最可能发生的事情是工作岗位从过去的不断细化的趋势开始变得不断泛化。现在你还在那区分前后端工程师属实是一个笑话，各种软件工种现在都可以统称为工程师岗位，如果一个后端工程师现在还写不好前端需求只能说明你不是一个合格的工程师。而所有工程师的工作会变成编排管理成百上千 Agent 的编码任务，解决 Agent 运行过程中遇到的无法自我解决的问题，帮助公司完善流程让 Agent 干活干得更舒心。