在这一周里，我完成了4个新需求，修复了6个Bug。如果放在去年，这足够我忙活一个月的。但这一次，4天搞定，97%的代码，是由AI完成的。
看着屏幕上自动生成的代码流，我脑海中回荡的是一个在技术圈被反复提及的概念：“Harness Engineering”。
那一刻，我突然意识到，我们正在经历一场软件工程的大变革。作为身处其中的架构师，我们不仅要问自己：当代码不再需要逐行敲击，我们还能被称为架构师吗？未来的市场，究竟需要什么样的开发者才能活下来？
从“砖瓦匠”到“驯兽师”
“Harness Engineering”精准地概括了我们当下的处境。
过去，我们像是砌墙的砖瓦匠，每一行代码都是我们亲手搬上去的砖头。我们以此为荣，因为那是我们手艺的证明。而现在，大模型是一匹日行千里的烈马，它拥有无穷的力量和速度，但如果没有缰绳，它只会漫无目的地狂奔，甚至把你甩下悬崖。
我的这97%的AI代码，就是那匹烈马跑出的路程。而我的工作，不再是跑步，而是设计Harness。
这不仅仅是写几个提示词（Prompt）那么简单。试图把所有规则塞进系统提示词是行不通的，因为长对话会稀释规则的权重。真正的Harness，是构建一套上下文权限、强制执行的Hooks、以及自动纠错的反馈闭环。
我现在的工作流，本质上是在做一个“城市规划师”。我不再关心某条下水道怎么挖（AI会做），我关心的是整个城市的排水系统会不会在暴雨天瘫痪。
活下来的特质：不仅仅是“会提问”
很多人说，未来的程序员只需要会“提问”就行。但我最近的实战经验告诉我，事情没那么简单。如果你只是会聊天，你很快会被更会聊天的AI取代。
要在2026年及以后活下来，我认为程序员必须具备以下三种“反脆弱”的特质：
构建“确定性”的能力
AI的本质是概率，它每一次生成的代码都可能不同。而软件工程的核心诉求是确定性。
能够活下来的程序员，是那些能够用概率性的AI构建出确定性系统的人。
这要求我们具备极强的系统思维。你需要知道在哪里设置“关卡”（Hooks），在哪里进行“验尸”（测试），以及如何设计影子测试来确保AI重构的老旧代码和原来一模一样。如果你无法判断AI生成的代码是“看起来能跑”还是“真的能跑”，那你就是那个在裸泳的人。
“业务知识回写”的守护者
代码可以重构，甚至可以用AI重写，但业务里的“为什么”一旦丢失，系统就会变成一堆无法维护的垃圾。AI可以写出完美的排序算法，但它不知道为什么在这个特定的金融场景下，我们需要一种特殊的排序逻辑。
未来的程序员，将是业务逻辑的考古学家和记录者。我们需要强迫AI在完成任务后，把决策理由、边界情况记录下来。这种将隐性知识显性化的能力，是AI目前难以替代的，也是企业最宝贵的资产。
拥有“品味”的架构师
当代码生成的成本趋近于零，选择的价值就无限放大了。
完成一个功能，可能有三种路径。AI可能会给你最通用的一种，但一个有经验的工程师知道哪一种最“便宜”、哪一种最“稳健”、哪一种最符合当下的技术债务状况。
这种“品味”，来自于对底层原理的深刻理解。这正是我最担心的地方——如果初级程序员不再通过写代码来磨练手感，他们如何获得这种“品味”？
所以，能够活下来的，是那些即使不写代码，也能一眼看出代码“味道”不对的人。是那些在AI给出一个“看似完美”的方案时，能敏锐察觉到潜在并发风险或安全漏洞的人。
Harness Engineering实操案例：如何设计“缰绳”
为了更清晰地说明Harness的设计，我以最近的一个项目为例，分享一下我是如何搭建这套系统的。
Harness全景流程概览
整个Harness系统是一个闭环的控制流，从意图注入开始，经过规划、执行、审查，最后以知识回写结束，形成一个自我进化的循环。
上下文管理与意图注入
我不会把所有业务逻辑都塞进一个巨大的提示词里。相反，我采用了分层策略：
- 核心规则（硬约束） ：放在
.cursorrules或类似的系统级配置中，例如“禁止使用已废弃的库”、“必须包含单元测试”。 - 业务知识（软约束） ：存放在独立的
knowledge/目录下，按模块划分。AI在生成代码前，必须通过MCP（Model Context Protocol）检索相关业务知识。 - 任务意图：通过
user prompt注入，只包含当前任务的简短描述。
强制执行的Hooks
这是Harness的核心。我定义了几个关键的Hooks，在AI生成代码的特定阶段强制触发：
pre_generation_hook：检查当前上下文是否完整。如果缺少必要的业务知识文件，强制AI先请求读取，而不是盲目生成。post_generation_hook：代码生成后，自动运行Linter和Formatter。如果不符合规范，直接将错误信息反馈给AI，要求其修正，而不是让我来手动改。pre_commit_hook：在提交代码前，强制运行所有单元测试。如果覆盖率下降或测试失败，拦截提交，并告诉AI：“此路不通，请修复测试。”
双阶段审查与知识回写
我不再让AI一次性审查所有问题。我设计了两个独立的Sub-agent：
- 功能审查Agent：只关心“功能对不对”。它会对比需求文档和生成的代码逻辑，确保没有遗漏。
- 质量审查Agent：只关心“代码好不好”。它会检查代码风格、潜在的性能问题、以及是否符合架构规范。
这种分离让AI的注意力更集中，审查质量显著提升。
这是最关键的一步。在任务完成后，我会触发一个专门的“回写”流程：
# 伪代码示例
ai_task_complete:
extract_business_rules()
update_knowledge_base()
log_decision_reasoning()
AI必须将本次任务中涉及的新业务规则、决策理由（比如为什么选择A方案而不是B方案）、以及遇到的边界情况，更新到knowledge/目录下的对应文件中。
这确保了我们的知识库是活的，每一次开发都在让系统变得更聪明。
结语：保持清醒，保持痛感
我们失去了敲击键盘的快感，但获得了驾驭系统的自由。这既是机遇也是挑战。我们必须时刻警惕，警惕自己沦为AI的“搬运工”，警惕自己对系统失去掌控力。
未来的程序员，不是代码的生成者，而是意图的表达者、质量的守门人和系统的驯兽师。
如果你还在纠结于语法糖，请抬起头来看看。草原上的烈马已经备好，关键在于，你手里是否有那根缰绳。
