开头的犹豫
注册了这个账号，想给自己留个地方把探索 Vibe Coding 工程化过程中的所思所学记录下来。这篇是头一篇，开了好几次头，都没能写下去。
倒不是没东西可写，而是想法比较零散，越想越觉得自己也没有什么成型的架构答案。用 AI 写代码大概有 2 年了，从最早靠 tab 预测蹭几个补全，到让 Agent 完整实现局部功能，再到几乎把一切都交出去的重度 Vibe Coding。期间踩过各种坑也烧掉了大量 token 然后凑出一些自己的总结。
不过与其说是总结，更准确的描述应该是随想（梦到什么说什么了属于是[手动狗头]）。
本文是 Vibe Coding 工程化 专栏里的一篇。专栏收集与整理 Vibe Coding 工程化的设想与落地实践。
Baton Stack 是面向「委托协作」的全栈脚手架——建立在一套持续演进的理论语料之上，好让人、Agent 与子 Agent 任意组合时，也能在长期交付中稳妥地把工作交出去、接得住。
先说清楚前提
以下思路有个前提：人类还需要负责细节裁决。也就是说，这些思路针对的是当下这个阶段，Agent 能力还不足以自主走完全流程，人在中间是真正有意义的。
不过 Agent 能力一直在提升，顺着这个方向想下去，大概能看到两条可能的路。
一条是软件开发全流程 Agent 化，到那时 Vibe Coding 的决策权不再由人拍板，而是让步给更高层的决策专用 Agent，人类决策权往上退了一层。
另一条更激进一些：随着 LUI（Language User Interface）逐渐成熟，软件层的开发需求本身极度弱化。用户直接面向产品的数据层，常规的软件前后端被替代。Agent 变成用户与数据层的中间代理，直接面向用户端具体的输出载体（音频、传统图形界面、VR、AR、MR、甚至脑机接口等），根据用户具体的需求实时产出高定制化的 UI 结果。现在费心设计的产品功能，尤其是前端部分，可能会慢慢变成一种落后的「预制 UI」。
仅就这两条路线而言，我个人长期比较看好 LUI 的发展方向，不过短期来看，Agent 全流程赋能软件开发这个方向正以极快的发展速度冲击着传统开发模式。无论是两者二选一亦或是二合一，Coding 层本身在相当长时间内仍然是没法被代替的，因此这里先学习和记录 Vibe Coding 工程化 的相关思路和落地探索，之后基于此经验扩展至软件开发全流程 Agent 化的探索（期待能将这些思路带入具备实际工程需求的团队中落地验证，也欢迎有共同兴趣的朋友交流探讨）。
当然，以上只是个人随想，如果你对未来的演进路径有完全不同的洞见，也非常希望能一起交流。
Vibe Coding 的两面性
爽的部分很直观，跟 Agent 说几句需求，几分钟后一坨能跑的代码就出来了，这种即时反馈让人上瘾（对我个人主要从事的 Web 前端开发来说，因其大部分开发场景下本身就具备所见即所得的开发模式，所以对这种即时反馈的体验更为依赖）。
隐忧也一样真实。同一个需求，今天让 Agent 写和明天让 Agent 写，或者换个模型写，实现思路和代码结构常常都不一样。更麻烦的是，Agent 的输出严重依赖现有代码质量（而那些代码，大部分也是 Agent 写的），随着时间推移和功能迭代，这种偏差会慢慢放大。还有一层现阶段事实上存在但更隐蔽的问题：我们写给 Agent 的规则文件，本质上是被动的。会话越长，那些约束就越往上下文底部沉，Agent 开始绕过这些约束，而人很难察觉。
放到团队里还有更坏的情况，每个人对 Agent 的熟练程度不同，用的模型也参差不齐，各自产出的代码质量本就层次不一，一旦合并到同一个仓库，Agent 下次参考的「现有代码」就掺进了所有人的输出，偏差互相传染，逐渐形成一个谁也说不清来源的屎山闭环。项目一大，整个仓库就变成了谁也不敢动、也不知道为什么是这样的东西。
有一阵我以为这只是 Agent 还不够强，但后来我慢慢改了想法。
重新思考优化目标
古法编程工程化的一切实践，如果刨到最底层，优化的是同一件事：降低人类认知负荷。
为什么要命名规范？因为人需要语义线索才能快速定位意图。为什么要设计模式？因为那是程序员之间的共享知识库，可以减少沟通成本。为什么要低耦合高内聚？因为人的工作记忆容量有限，一次只能推理有限数量的依赖关系。为什么要 Code Review？因为人会犯错，另一个人的眼睛是纠错机制。
所有这些要求本质上都服务于一个隐含假设：代码是人与人之间的通信介质。写代码的是人，读代码的是人，改代码的还是人。整套工程化体系，是围绕「人类作为代码的读写主体」这个前提构建的。
但如果深挖这套体系存在的根本原因，会发现它是一种特定不对称性的产物：人类的意图理解和记忆能力强，编码执行力相对较弱。 Vibe Coding 把这个不对称性反转了。Agent 的编码执行力远超在中高层意图的持续理解和跨上下文记忆：它没有「我记得当初为什么这么写」的背景知识来兜底，也没有跨越会话的意图连续性。瓶颈从执行侧移到了意图侧，工程化的优化重心也必须跟着移动。
这里有一个容易产生的误判：既然 Agent 负责执行，可读性和可维护性是不是就不再重要了？恰恰相反。可读性的工程价值并没有消失，只是受益对象从人类转移到了 Agent。 Agent「参考现有代码」时，代码质量直接决定了它推理的质量上限。一个命名混乱、结构随意的代码库，对 Agent 意图推断能力的干扰不亚于对人类的干扰（甚至更大），因为 Agent 无法像熟悉项目的人那样用背景经验弥补代码表达的缺失。
因此，可读性的定义需要扩展：从「让人读懂」升级为「让人和 Agent 都能从中提取意图」。两者在大多数情况下方向一致，但并不完全重合——有些对人类友好的写法对 Agent 并不友好，反之亦然。这个差异地带，本身就是 Vibe Coding 工程化值得深挖的地方。
| 编码模式 | 相对优势 | 瓶颈所在 | 工程化目标 |
|---|---|---|---|
| 古法编程 | 意图、记忆强 | 编码执行力较弱 | 让代码对人可读可维护 |
| Vibe Coding | 执行力强 | 意图传递可靠性差 | 让意图可识别、可锚定 |
这个认知的转变，是后面一切具体思路的出发点。
核心支点一：意图识别
Agent 不会因为意图模糊而停下来，它会用局部信息补全剩余的空白，然后自信地交付一个看起来完整、但方向也许错误的结果。
意图不只是 prompt
先澄清一个容易被忽视的前提：意图不等于每轮对话里人工输入的那条 prompt。
意图是更广义的东西：
- 项目在业务上的产品方向与产品设计
- 规则文件里写下的约束
- 代码注释里的设计说明
- Git 记录里的上下文
- 团队约定俗成但从未文档化的判断标准
- 甚至包括人类自己尚未意识到、直到 Agent 给出偏差答案时才浮现的隐含假设
之前我把意图等同于 prompt，沉迷于提示词工程中的各种技巧，致力于如何让自己的表述更加全面且无歧义，直到重度 Vibe Coding 大幅度提升交付效率之后，才从这个狭隘的视角中解脱出来。
意图有两个维度
横向：意图的层次。 一个完整的意图至少有三层：
- 目标：想要什么
- 约束：不想要什么
- 背景：为什么这样要
早期我大多数情况下几乎只给到第一层，第二和第三层是隐含的，连自己都不总意识得到，直到 Agent 字面满足了第一层却违背了第二层，才后知后觉。
纵向：意图的粒度。 意图天然分布在不同决策层级上：
- 战略层：业务目标、产品定位、核心用户价值，稳定性最高，变更需要跨角色共识，约束力覆盖全局
- 架构层：技术选型、模块边界、系统约束，中等稳定，变更影响多个模块，约束力覆盖实现边界
- 实现层：局部逻辑、接口设计、具体写法，高频变更，约束力仅限于当前上下文
每一层的稳定性来源不同，变更代价也不同。高层意图对低层决策有约束力，低层意图只能在高层框架约束内自由裁量。
问题在于，Vibe Coding 里这两个维度几乎从不被显式区分，结果往往是双向失效：
- 低层随机决策向上污染：一个模块里的临时做法，因为 Agent 后续会「参考现有代码」，逐渐被当作项目惯例沉淀下来
- 高层约束被单次 prompt 击穿：项目层说好不引入新的状态管理库，某次顺手说「这里加个全局状态」，Agent 就去装了
意图识别的主体问题
直觉上，说清楚意图是人的责任，但这有个根本缺陷：人类不知道自己不知道什么。 隐含假设在没被触碰之前不会浮出来。
更合理的模型是反过来：由 Agent 主动澄清模糊意图、暴露隐含假设、识别意图矛盾，这些是 Agent 的职责，而不是人类输入的前置条件。需要被设计的不只是「怎么写 prompt」，还有「Agent 该如何把检测到的模糊点和隐含假设暴露出来」。
从文档态到协议态
现在大多数工作流里，意图的主要载体是规则文件。前面说过这些文件是被动的，但被动只是表象，更深的问题是：规则文件是文档，不是协议。
文档是静态单向的，有没有被用到、用对没有，全是黑盒。意图要真正起作用，需要被锚定到具体执行步骤，有证据证明它被应用了，偏差时触发反馈而不是静默通过。这和代码工程化里「可测试性」的逻辑相同：我们不相信代码是对的所以写测试，同理，我们也不该相信意图被正确理解了。
意图衰减的三种形式
前文把这个问题简单描述为「会话越长规则往底部沉」，但这只是其中一种：
上下文窗口衰减：最常被讨论，也最表面。
语义漂移：随着迭代，代码库实际状态和最初意图之间出现偏差，后续意图在一次次「参考现有代码」中被悄悄替换。
假设腐烂：隐含假设随项目演化失效，但没有机制去更新它，所有依赖这个假设的意图跟着一起失效。粒度层越高的假设腐烂，破坏面越大（如果不分层，就很难意识到一个失效假设究竟在多大范围内埋了雷）。
这些加在一起，指向同一个结论：
意图识别不是「开始前把话说清楚」的问题，而是贯穿整个开发流程的持续性工程问题。 它需要的不是更好的 prompt 模板，而是一套让意图在整个执行链条上保持可见、可验证、可追溯的机制。
核心支点二：意图锚定
本节从 Zoro: Active Rules for Reliable Vibe Coding 的研究成果中获得了关键性启发。
一个被完整识别出来的意图，如果在执行过程中无声无息地消失了，识别本身就是徒劳的。
执行是意图的杀手
直觉上，意图丢失主要发生在识别阶段，但实际上存在大量意图丢失发生在 Agent 已经理解意图之后的执行阶段。这不难解释。执行是一个将抽象意图逐步展开为具体代码的过程，每一步展开都伴随着决策（用哪个 API？怎么组织数据结构？错误怎么处理？……），这些局部决策各自都有局部最优解，而局部最优解不一定和全局意图一致。
人类开发者面临同样的困境，但人类有持续的内在意识来维持全局视角（虽然也经常失败），目前 Agent 没有这样的机制。Agent 的每一步决策，本质上是在当前上下文窗口内做局部推理，全局意图只是上下文中的一段文字，和当前函数的局部逻辑争夺同一份注意力资源。
把这个过程拆开看，意图在执行中至少经历三次损耗：
第一次：生成计划。 Agent 将自然语言意图转化为执行计划，这个过程本身就是一次有损压缩。计划通常只保留了意图中「做什么」的部分，「不做什么」和「为什么这样做」在计划中几乎不留痕迹。约束和背景在这一步被默默丢掉，后续执行自然也不会遵守一个不存在于计划中的东西。
第二次：逐步展开。 即使计划完整，Agent 在逐步写代码时，注意力焦点会不可避免地收缩到当前文件、当前函数。全局约束和局部实现之间的距离越远，约束被遵守的概率越低。这不是能力问题，而是结构性问题：现有的 Agent 执行模式缺乏一种机制能在每一步把全局意图拉回注意力焦点。
第三次：上下文污染。 Agent 不是在真空中写代码，它参考已有代码。如果已有代码中已经包含了偏离意图的实现（而这些实现可能也是 Agent 之前写的），那后续执行就会把偏差当作「项目惯例」继承下来。意图在这里不是被遗忘，而是被替代，被一个从代码库中归纳出来的、并不正确的「隐含意图」替代了。
这三次损耗叠加在一起，解释了一个反直觉的现象：项目初期 Vibe Coding 的效果往往很好，但随着迭代推进，质量会加速下滑。 每一轮执行的损耗不是独立的，而是累积的，上一轮的偏差成为下一轮的输入，正反馈回路一旦形成，就很难从内部打破。
黑盒问题
意图在执行中丢失，还有一个更隐蔽的原因：人类看不见执行过程。
古法编程过程中，代码是人一行一行写的，每一步决策都经过人的意识，即使写出了偏离意图的代码，人在写的过程中至少有机会察觉。Vibe Coding 把这层可见性彻底去掉了，Agent 在后台改了几十个文件，人看到的只是最终的 diff（或者连 diff 都不看，只看功能跑不跑得通）。
这意味着什么？意味着人类的「细节裁决权」在当前的执行模式下是一种幻觉。你没法裁决你看不见的东西。功能跑通了，不等于意图被遵守了。一个函数可以用完全违反项目架构约定的方式实现，但功能上毫无问题，人类在黑盒执行模式下几乎不可能捕捉到这种偏差。
所以意图锚定的第一个前提，不是让 Agent 更聪明，而是让执行过程对人类可读。不是要求人类像传统 Code Review 那样逐行审查（那等于放弃了 Vibe Coding 的效率优势），而是在执行链路中建立一种「信号层」，让人类能以极低成本感知到：哪些意图被考虑了，哪些被跳过了。
信任的破产
这里有一个根本性的认知转变需要发生。当前 Vibe Coding 的默认模式是信任模式，人类输入意图，然后信任 Agent 会遵守。意图的主要载体（无论是规则文件、代码注释、还是口头约定）本质上都是一份「请遵守这些」的声明，它假设 Agent 接收到了就会照做。这和把公司制度打印出来贴在墙上是一个逻辑。
因此意图的落地不能依赖信任，必须依赖某种可被观测的证据。
证据在这里不是 Agent 说「我遵守了」（那是自我声明，不是证据），而是执行过程中可以被独立验证的痕迹：某条意图在哪个具体决策点被应用了，应用的方式是什么，产出的代码如何体现了这条意图的约束。
但这里有一个微妙的问题值得注意：让 Agent 自己证明自己遵守了意图，存在循环论证的风险。这不意味着证据机制无效，但也必须承认这层机制本身的可靠性上限取决于具体落地的验证方式（可考虑的方向有 Agent 自证、Sub Agent 独立验证、传统静态分析工具等等），而不仅仅取决于是否要求了证据。
意图锚定的阶段性策略
意图在执行中的三次损耗发生在不同阶段，对抗它们的策略也应当分阶段设计。
对抗第一次损耗：在计划中显式嵌入意图。 生成计划是意图丢失的第一道关口。如果在这个阶段就把意图的各个维度（目标、约束、背景）显式标注到计划的每个步骤上，不是笼统地说「请遵守以下意图」，而是在每个具体步骤旁边标明「这一步受意图 X 和意图 Y 约束」，那么后续执行时，Agent 在处理每一步时至少有一个显式的锚点可以参照。
这和建筑施工的逻辑类似，规范不是一本放在工地办公室的手册，而是标注在施工图纸每个节点上的具体要求。前置锚定做到的核心事情是：把意图遵守从 Agent 的自觉行为，变成执行流程的结构性组成部分。
对抗第二次损耗：在每一步执行中重新激活意图。 前置锚定解决了「计划里有没有意图」的问题，但没有解决「Agent 写代码时还记不记得意图」的问题。注意力收缩是执行展开的必然副作用，Agent 越深入当前文件的局部逻辑，全局意图就越容易被挤出工作焦点。
对抗这一层损耗的方向是：在执行的每一步设置意图的「检查点」。不是让 Agent 在写完所有代码之后回头检查一次（那时偏差已经固化），而是在每个关键决策节点都将与该节点相关的意图重新拉入当前上下文核心。这本质上是一种「意图的实时伴随」机制：意图不是在起点被声明一次然后放手，而是像影子一样跟随执行的每一步，在每个可能发生偏离的节点主动出现。代价是显而易见的，更多的上下文消耗、更慢的执行速度，但这个代价换来的是偏差的早期发现而非末端堆积。
对抗第三次损耗：建立代码库的意图基线。 上下文污染的根源不在当前这一次执行，而在代码库本身已经积累了偏离意图的实现。Agent「参考现有代码」这个行为无法被禁止（这是它理解项目上下文的基本方式），但可以改变它参考的是什么。
可能的方向是：为代码库建立一层意图基线，不是代码层面的 lint 或格式规范，而是语义层面的标注，标明每个模块、每个关键决策背后的意图是什么、为什么这样做、不应该怎样做。当 Agent 参考现有代码时，它读到的不仅是代码本身，还有附着在代码上的意图元信息。如果当前代码的实现与其标注的意图不一致，这个矛盾本身就是一个信号：要么代码需要修正，要么意图需要更新。这层基线让「参考现有代码」从一个无差别的模仿行为，变成一个有意图校准能力的参照行为。
反馈回路：让意图自我修复
到目前为止的讨论都集中在一个方向：如何让已有的意图在执行中不丢失。但还有一个同样重要的问题：意图本身可能是错的、过时的、或者不够具体的。
如果执行过程中有证据机制，那证据不仅可以用来验证遵守，还可以反哺意图的修订。当人类审视某条意图的执行痕迹时，可能会发现三种情况：
- 意图被正确遵守了，且产出符合预期 → 这条意图本身是有效的，确认并沉淀
- 意图被遵守了，但产出的结果不理想 → 意图的表述或方向本身需要修订
- 意图在某个具体场景下无法被遵守 → 这条意图可能过于绝对，需要补充边界条件
这些反馈如果能被结构化地捕获并用于更新意图，那意图就不再是一个写完之后只能等着腐烂的静态产物，而是一个随着执行经验持续进化的活的系统。
这里的关键洞察是：执行不只是意图的下游，也是意图的上游。 执行产出的痕迹和偏差，是意图自我修正的信号源。如果只有「意图→执行」的单向链路，意图会不可避免地和现实脱节；只有建立「意图→执行→证据→反馈→意图更新」的闭环，意图才能在项目的生命周期中保持生命力。
核心支点三：意图治理
从单体到多体
前两章的讨论有一个隐含前提：意图的来源是单一的。在这个前提下，意图识别和锚定已经够难了，但至少问题的边界是清晰的，你只需要和自己的模糊性作战。
多人协作把这个前提抽掉了。意图的来源变成了多个独立的大脑，各自带着各自的隐含假设、优先级排序、和对「好代码」的不同直觉。每个人都在通过各自的 prompt 向同一个代码库注入意图，而 Agent 无差别地参考现有代码，它不区分哪段代码背后的意图经过了共识，哪段只是某个人的临时判断。
混乱的团队协作真正破坏的不是单次执行的可靠性，而是一个更底层的东西：意图的一致性。
冲突是必然的
单人场景下意图冲突是偶发的，多人场景下意图冲突是结构性的、必然的。
两个开发者对同一个模块有不同的实现偏好，各自的 Agent 产出了风格迥异的代码，合并后，下一个 Agent 面对的就是一个内部自相矛盾的代码库。前面描述的「屎山闭环」，根因不是代码质量差，而是代码库中嵌入了互相矛盾的意图，且没有任何机制去检测和仲裁这种矛盾。
传统开发中 Code Review 部分承担了意图仲裁的功能，Reviewer 会说「这里的做法和我们之前的约定不一致」。Vibe Coding 中这层人工仲裁被大幅弱化甚至跳过了，而没有替代机制补上。
这指向一个关键问题：意图冲突需要在意图层面被检测，而不是等它沉淀为代码冲突后才被发现。 到代码层面再修复，你不只是在改代码，你是在逆向追溯意图来源、判断优先级、然后重写，成本完全不同。
分层治理
解决这个问题的思路，要回到支点一提出的意图纵向分层（战略层 → 架构层 → 实现层）。这个分层在单人场景下是分析工具，在多人场景下必须变成治理结构。
核心逻辑是：不同层级的意图应该有不同的变更权限和验证强度。
战略层意图低频变更，变更需要显式共识，约束力向下穿透；实现层意图高频变更，在上层约束框架内允许个人自由裁量。关键不是在每一层都建立重型机制，而是保证层级之间的边界是清晰且可执行的，只要战略层和架构层的意图稳定且被一致遵守，实现层的多样性可以被容忍。
当前 Vibe Coding 的问题恰恰是所有意图都跑在同一个权限层级上。一条 prompt 既可以调整局部实现，也可以有意无意地改变架构决策，Agent 不区分这两者，人也往往没意识到自己越权了。
意图的时间维度
多人长周期项目还会系统性地暴露支点一中提到的「假设腐烂」：意图有时效性，但当前没有机制标记它的有效期。
一条「不引入新的状态管理库」的规则，可能在技术选型阶段是绝对约束，到架构稳定后变成强约束，到面临重构时变成可商议的。但在当前的规则文件中，这条规则从写下到被删除之间权重恒定。A 三个月前写了一条规则，B 今天加入项目，不知道这条规则的时代背景，B 的 Agent 要么盲目遵守一条可能已经不适用的规则，要么悄悄突破它而 A 完全不知情。
意图在时间维度上需要携带足够的元信息，不是设置过期时间，而是使其适用性可以被评估，而非只能被盲目执行。
代码库作为意图的考古现场
还有一层容易被忽视的问题：代码库是所有历史意图的物化沉淀，但当前没有任何元信息把代码和产生它的意图关联起来。
你看到一个函数，大部分情况下往往不知道它是出于什么意图被写成这样的，不知道写它时有哪些约束在生效，不知道它是深思熟虑的决策产物还是 Agent 某次随机选择的结果。单人短期项目中你自己记得，规模扩大后这变成核心瓶颈——新成员和 Agent 一样，面对没有意图标注的代码库只能「猜」，而猜的结果往往是错的。
如果代码能被追溯到产生它的意图和决策上下文，Agent 下次「参考现有代码」时就能区分：这是项目层约束的产物，必须遵循；这只是上一次的临时实现，可以重新决策。
共识成本的悖论
以上每一条如果直接落地，都会面临同一个现实问题：共识太贵了。 如果每条意图都需要全员共识、每次冲突都需要显式仲裁、每段代码都需要意图标注，Vibe Coding 的效率优势就被管理开销吞掉了。这和传统工程化的困境如出一辙，过度的流程规范同样会杀死生产力。
这也是我认为意图治理在三个支点中工程实现难度最高的原因。它本质上是一个优化问题：在意图一致性和治理成本之间找到当前阶段的最优平衡点。 而这个平衡点会随着 Agent 能力的提升、团队规模的变化、项目复杂度的增长而持续移动。
目前我还没有一个成型的答案。但有一个方向性的直觉：治理的重心不应该是管人，而是管意图的层级边界。只要层级边界足够清晰，高层稳定性就能为低层的自由度提供安全空间，治理成本就可以集中在少数高杠杆的节点上，而不是分散在每一次日常开发中。
写在最后
意图需要被识别，被锚定在执行链路上，在多人协作中被治理成一个一致的体系。三件事，三个支点，它们共同服务于同一个目标 —— 让 Vibe Coding 产出的可靠性不随时间和规模衰减。
老实说，我不确定这些设想最终能不能站得住。它非常主观，带着我自己过往经验教训的偏见。
我只是觉得，AI 写代码这件事变化太快，与其等一个「标准答案」，不如先把脑子里的想法写下来，方便日后反思、也方便被推翻。如果它能给同样在琢磨 Vibe Coding 该往哪走的你一点启发，就已经很值了。
另外还有一个想法，是在写这篇文章的过程中才慢慢浮现在脑中的：
// TODO: what, then, would even be the right TODO?
console.warn(`
我越来越觉得，代码本身并不是 Vibe Coding 真正产出的东西，
它产出的是产品意图的一种瞬时表达。
代码只是意图在某个时间点、某个技术约束下的投影，
它没有内在价值，只有工具价值。
既然如此，代码最终走向黑箱几乎是必然的。
当表达意图的方式足够成熟，
中间这层人类可读的符号体系就会像汇编语言一样，
退出前台，进入底层。
我们现在做的一切工程化努力，
与其说是在维护代码，
不如说是在为这个过渡期搭建脚手架。
脚手架的使命，本来就是在建筑竣工后被拆掉的。
`);
后续我也会将本文思路作为骨架，在具体的 Node.js 生态中进行落地实践（其实更适合在 Agent 工具内部实现，但螺丝还得接着打，因此选择了一个目前对我个人来说成本较低的技术方向），并不断完善骨架和补全细节。
最后非常感谢能阅读到此处的朋友，期待与君共同「无限进步」。
