当你把编程过程交给人工智能去完成时,真正的工作并不是敲代码,而是定义问题、设定边界、验证结果和承担决策。一次把老牌配置语言重写为 JavaScript 模块的经历,成为检验这个观点的绝佳案例。这篇文章讲述了用 vibe-coding 方法实现配置解析器时的关键步骤、遇到的细节、得出的教训以及对工程实践的可复制建议。 故事从一种看似简单的配置语法开始。语法原型允许按行定义命令,每行可携带若干以短横开头的参数,参数可带值也可以不带值。表面上它像一个小型 shell,但在边缘案例、空值、转义和注释处理上存在复杂性。
最初的 C# 版本已经稳定运行多年,但需要一个轻量的 JavaScript 重写以便在新项目中复用。由于对编写解析器的枯燥和反复调试心存抗拒,作者决定采用 vibe-coding:用 AI 快速生成实现,同时把更多精力投入到规范和验证上。 第一步是把语言细节写成规格文档。作者没有尝试写形式化的语法定义,而是用大量示例和自然语言描述每个语义点,覆盖分隔符、参数存在与否、带冒号但无值的含义、注释风格、多行命令等多种情况。这个文档花了约九十分钟起草,但真正的价值在后续。作者将文档交给 AI,让它指出不清晰或自相矛盾的地方。
AI 很快发现了几十处问题,其中既有啰嗦的措辞,也有真实的设计决策缺位,比如参数后缀冒号应当如何解释:不带冒号的参数是否意味着布尔真;带冒号但没有值是否应当视为空字符串。AI 的提问逼迫作者为这些边界做出明确决策,从而让语言变得可实现、可测试且一致。 这一轮文档驱动的设计过程本身就是价值所在。通过和 AI 反复对话,作者把许多隐含假设外显化并封装成规则。AI 的"无历史偏见"视角有助于当作一种外部审稿人,它会把作者习以为常但未写明的假定变成问题清单。对一个团队来说,把这些问题形成在案比直接动手编码更能降低后期返工成本。
确定规格后,作者要求 AI 在 Visual Studio Code 的 agent 模式下生成单文件 JavaScript 模块,导出所有类并且不依赖外部库。同时要求附带单元测试,以便验证实现是否与规格一致。AI 在十四分钟内生成了初稿实现和相当数量的测试用例。通过几轮小的提示改进,最终实现通过了全部测试,性能表现也令人满意:一个复杂的配置片段解析时间在毫秒级以下。作者审视了代码,发现并无复杂的递归下降或解析器组合器,更多是行级字符串拆分和状态机式的条件处理。这种"暴力"实现满足了无依赖、可理解、可维护的目标。
从这个过程可以抽象出多条可操作的经验。首先,vibe-coding 适合那些目标明确且结果可以客观验证的任务。配置解析器就是典型场景,因为输入到输出之间有明确的映射关系,并且可以通过单元测试反复校验。将更多时间花在规格书和测试用例上,能显著降低实现环节的不确定性。 其次,把设计和边界条件写成文档后再交给 AI,收益极大。人类往往会忽视一些常识以外的边缘情况,而 AI 在阅读规格时会以严格逻辑审视其矛盾与模糊点。
把文档当作合同对待:每一条未定义或模糊的行为都可能在实现时成为漏洞。让 AI 扮演规范审查者,可以提前捕获这些风险。 第三,约束生成环境和实现边界非常关键。要求单文件、无依赖、模块化、导出纯粹函数或类,会促使 AI 生成更易维护的产物。这样的代码更容易审查、测试和集成,也避免了隐式复杂性或不可控的第三方引入。把"边界"写清楚,比期待 AI 自主作出架构判断更可靠。
第四,测试并不是可有可无的附加物,而是验收标准。作者要求 AI 生成大量单元测试用例,以覆盖正常路径和异常路径。测试用例同时充当规格示例,任何实现偏离规格都会导致测试失败,从而形成良性循环。对于依赖 AI 生成实现的场景,自动化测试是信任建立的核心手段。 第五,vibe-coding 并不等于偷懒。相反,工作形态发生了转变:从书写底层细节代码转为花时间做设计、制订规则和校对 AI 的输出。
作者将时间主要投入到写规格、反复和 AI 讨论、以及迭代测试上,这些工作在传统的编码模式下也同样重要,但在 AI 辅助下显得更加集中和高产。 第六,需要外部的第二意见。作者用 AI 来做文档审查,但同样强调人类评审的重要性。AI 能发现逻辑矛盾和不一致,但有些语境性或产品级别的权衡仍需团队决策。把 AI 的反馈视为红队输入而非最终裁决,可以把风险降到最低。 在实践中也出现了一些需要注意的局限和风险。
AI 生成代码的实现方式往往偏向直观且简单,不一定是最优或最优雅的。对于性能敏感或需要扩展性的场景,暴力式解析可能在早期可行,但随着语法复杂化或输入规模增长,重构成本可能会相对增长。因此在决策阶段就应评估未来演进的可能性,并决定是否需要更系统的解析方案,例如形式化语法、解析器生成器或更抽象的数据模型。 另一个风险是可维护性。虽然单文件无依赖的模块易于理解与集成,但随时间推移,功能需求会膨胀,单文件设计可能成为负担。建议在初期保留清晰的模块边界和抽象接口,使未来拆分与重构更容易。
安全性也是不可忽视的话题。配置解析器直接接触用户提供的文本,它必须对注入、资源滥用、错误回溯信息泄露等问题保持警惕。即便当前实现不涉及执行代码,也应当在设计阶段考虑限长、拒绝危险字符、对外部依赖进行沙箱等防护措施。 在与 AI 协作生成代码时,提示工程的好坏直接决定产出质量。有效的提示包括明确的输出格式要求、错误处理策略、性能目标、边缘案例示例以及测试覆盖率要求。把提示写成对 AI 的不可变契约,能大幅减少来回迭代的次数。
同时,团队文化要适应这种新的工作流。vibe-coding 不是一次性把全部实现交给 AI 就结束的游戏。它需要工程师具备更强的规格写作能力、测试设计能力和审查能力。公司应鼓励把更多时间投入到问题定义与风控讨论,而不是把所有人推回到低价值的重复编码工作中。 对个人开发者来说,有几条实践建议特别适用。把语言规范和样例当作核心资产存档,使每次迭代或迁移都有清晰的回溯依据。
让测试用例覆盖典型场景和罕见边界,将测试视为规约的可执行文档。对 AI 输出进行代码审查,不要盲目接受自动生成的实现。为核心模块写性能基准并在版本升级时持续监控性能变化。 展望未来,vibe-coding 将在更多场景发挥作用,但不是万能钥匙。它最适合重复性高、规则明确、可单元化验证的子任务。对于需要创造性架构设计、系统级权衡或复杂算法的问题,人类工程师仍需主导。
在团队中合理分配人力与 AI 的角色,才能发挥协同最大效益。 回到那次配置解析器的实践,它最终成为一个稳定的、性能良好且维护友好的模块。更重要的是,通过文档驱动和测试驱动的方式,团队形成了一套可复制的工作模式:先把产品行为写清楚,再用 AI 生成实现,最后用测试验证并用人工审核完善。这个流程既节省了重复劳动,又把更多智力投入到高价值的设计决策上。 总结而言,vibe-coding 的真正价值不在于让机器代替开发者,而在于把开发者从机械性的编码工作中解放出来,集中精力做那些更难自动化的事:定义边界、评估风险并做出权衡。只要把文档、测试与审查放在首位,并对生成结果保持必要的怀疑与验证,AI 可以成为提升交付效率与质量的重要助力。
那些准备好改变工作方式并掌握新型协作技能的团队,将在未来的软件工程实践中处于有利位置。 。
