Diff 看起来很干净。Agent 导入了正确的模块，调用了看起来正确的函数，TypeScript 也没有报错。PR 描述甚至引用了文档。随后 CI 中的构建开始运行，调用却由于 TypeError: x is not a function 而崩溃 —— 这是因为该函数在八个月前的一次小版本更新中被拆分成了两个，而 Agent 是根据其训练数据中存在的库版本生成的代码，而不是你 package.json 中安装的版本。
这并不是“LLM 会产生幻觉”这一框架能让你做好准备的那种故障。模型并不是在发明一个从未存在的 API。它是在记忆一个曾经存在但现在已不存在的 API。Agent 进行推理的心智模型是一个冻结在训练时的快照。世界在向前发展。代码库在向前发展。而 Agent 却一无所知，因为没人告诉它。
几个月前，你的一个下游 API 返回了一个格式错误的时间戳——在应当显示毫秒的地方返回了秒，或者在 Schema 承诺返回字符串的地方返回了 null。你的智能体（agent）遇到了这个问题，分析了故障原因，并制定了一个修复方案：乘以 1000，或者回退到默认值，或者使用不同的端点重试。它解决了眼前的麻烦。然后，它做了一件产生深远影响的事：它记下了这个变通方案（workaround）。
也许它在长期记忆中保存了一条笔记：“计费 API 返回的时间戳单位是秒；使用前需转换。” 也许这次交互被卷入了一个微调（fine-tuning）数据集，于是这个变通方案变成了一个习得的反射行为。无论哪种方式，智能体现在都对世界产生了一种认知。而就在上周，API 团队发布了一个修复补丁。现在时间戳正确了。但没人告诉这个智能体。
当生产环境出现故障时，工程师们首先会想到 git blame。提交哈希值指向 PR，PR 指向作者，而作者则指向上下文——Slack 讨论串、设计文档，或者是记住了代码初衷的那个大脑。这条链路是团队排查事故、进行安全审计以及积累机构知识的方式。它假设每一行代码都有一个理解自己在做什么的人类作者。
AI 已经悄然打破了这一假设。目前约 46% 的代码由 AI 生成，在 Java 团队中，这一比例甚至超过了 60%。这些代码中的大部分都不携带任何有意义的溯源元数据。git blame 链条依然在运转——只是现在它终止于一名开发者，他们接受了一个可能并未完全理解的建议，而且没有记录提示词、模型版本或 AI 拒绝的备选方案。
AI 编程工具的 ROI 宣传在纸面上看起来无懈可击：在受控实验中，开发者完成任务的速度提升了 55%，合并的 Pull Request 数量增加了 98%，每周据称节省 3.6 小时。但当组织审视真实的交付指标——Bug 率、发布周期、故障频率——时，数字几乎没有任何变化。某些东西吸走了所有增益的时间，而它并不难找。
AI 数秒生成代码。工程师的审查速度，却和以前一样慢。
最迫切需要 AI 编程帮助的团队，通常并不是那些正在构建全新服务（greenfield services）的团队。他们往往正在维护 2012 年产出的 50 万行 Rails 单体应用，或是处理过数十亿笔交易的 COBOL 支付系统，亦或是架构师早在三次收购前就已离职的微服务网格。在这些代码库中，一个位置不当的重构就可能引入隐蔽的数据损坏漏洞，而这些漏洞往往在三周后的生产环境中才会浮现。
而这恰恰是目前的 AI 编程助手（agents）失败得最惨烈的地方。
令人沮丧的是，这种失效模式在爆发前是隐形的。AI 助手生成的代码可以通过编译，通过现有测试，并在审查中看起来非常合理。问题往往出现在预发环境（staging）、深夜的批处理作业，或者是某个客户在月份特定日期才会触发的边缘情况中。
这种规律在 2023 年和 2024 年采用编程智能体的团队中几乎普遍存在。第一个月，效率翻倍。第三个月，管理层把生产力指标拿出来，作为 AI 投资回报的证据。到了第十二个月，工程团队有一半的代码库已无法向新员工解释清楚，重构成本高得令人望而却步，工程师花在调试 AI 生成代码上的时间，比他们手写这些代码所需的时间还要多。
这不是一个关于 AI 代码暗中存在缺陷的故事。这是一个关于 AI 生成代码的质量特征如何系统性地瓦解团队已有的组织实践的故事——以及这些实践在技术债务复利失控之前需要如何改变。
每个曾将模块委托给外包的工程师都知道那种感觉：代码交回来了，测试通过了，演示也能跑——但你完全不知道它到底好不好。你没有写它，你不完全理解其中蕴含的决策，而你即将进行的审查更像是走过场而非真正的实践。现在把这种动态乘以你代码库中每一个AI辅助的提交。
AI委托悖论很容易表述，却很难逃脱：你最需要用来评估AI生成工作的技能，恰恰是你停止亲自动手后退化最快的技能。这不是未来的风险，而是正在发生的事实，在那些拥抱AI编码工具的工程组织中已经可以量化测量。
每个工程组织都有这样的人。他们不拥有产品，不交付用户可见的功能。但没有他们，一切都无法运转。他们是编写 ETL 管道、将数据从计费系统搬到分析仓库的工程师；是构建 Webhook 处理器、让 Salesforce 与内部 CRM 保持同步的人；是维护 API 适配层、让移动端应用能与三个从未被设计为相互通信的后端服务对话的人。
他们就是胶水工程师，而他们的工作是第一批被 AI 代理完全吞噬的软件工程类别。
你的智能体 v1 能用。它很丑，靠提示词胶带勉强维持，每次打开代码都让你皱眉。但它能处理 90% 的情况，用户很满意，每天都在创造价值。于是你自然而然地决定：从头重写。
六个月后，重写版本仍未上线。你迁移了两次框架，为一个根本不需要的问题搭建了多智能体编排层，评估套件测试的全是那些从不出错的地方，真正容易崩溃的地方一个没测。与此同时，v1 依然在跑——依然很丑，依然好用。
这就是第二系统效应，它在我们大多数人出生之前就已经摧毁了无数软件项目。
大多数运行 AI 编程智能体（AI coding agents）的团队都在优化错误的变量。他们过度痴迷于模型选择 —— Claude vs. GPT vs. Gemini —— 却将周围的脚手架视为次要的配套工作。但基准测试数据和生产环境的实战经验告诉我们一个不同的故事：一个在演示中令人惊叹的模型与一个能够可靠交付生产代码的模型之间的差距，几乎完全取决于其周围的控制环（harness），而不是模型本身。
这个公式看似简单：智能体 = 模型 + 控制环 (Harness)。控制环是除此之外的一切 —— 工具 schema、权限模型、上下文生命周期管理、反馈循环、沙箱环境、文档基础设施、架构不变性。如果控制环搞错了，即使是最前沿的模型也会生成虚构的文件路径，在会话进行到 20 轮时破坏自身的约定，甚至在没写任何测试之前就宣称功能已完成。
对于习惯于编码、构建和自动化的软件工程师来说，涉足量化交易是一个充满吸引力的领域。然而，第一个挑战便是选择合适的工具。你应该选择像 TradingView 这样整合良好、开箱即用的平台，还是投入 Python 生态系统的怀抱，享受其无穷的灵活性？
本文将从软件工程师的视角，深入剖析这两种主流方案的优劣，帮助你找到最适合自己的交易武器库。
TradingView 以其流畅的图表和庞大的社区而闻名。其内置的 Pine Script 是一种专为交易策略开发设计的领域特定语言 (DSL)。
ta.sma(close, 14) 这样简单的代码，快速实现复杂的技术指标。strategy()，即可使用内置的策略测试器进行回测，并获得详细的绩效报告（净利、回撤、胜率等）。其强大的警报系统可以通过 Webhook 将交易信号发送到任何指定的 URL，为半自动化交易铺平了道路。洞见：TradingView 是量化交易的绝佳入口。它专为可视化和快速迭代而生，非常适合用来验证基于技术分析的交易点子。它就像一个功能强大的 IDE，但专为交易图表而设计。
对于追求极致控制权和灵活性的工程师来说，Python 生态系统是必然的选择。以 Backtrader 和 Qlib 为代表的开源框架，让你能从零开始打造完全定制化的交易系统。
Pandas 处理数据、用 NumPy 进行高速运算、用 Scikit-learn 或 PyTorch 训练机器学习模型来产生交易信号。matplotlib 或 Plotly 代码才能实现。洞见：Python 赋予你无上的权力，但也要求你承担全部的责任。它适合那些目标明确、需要高度定制化、并且不满足于单纯技术指标分析的严肃交易者和量化研究员。
那么，你该如何选择？答案取决于你的当前目标和技术深度。
如果你是首次涉足量化交易，或者只是想快速验证一些交易点子： 首选 TradingView。它的即时反馈和可视化特性无可匹敌。你可以专注于策略逻辑本身，而不用分心于基础设施的搭建。在这里，你可以快速学习什么是有效的，什么是无效的。
当你发现以下情况时，就该考虑 Python 了：
这是一个在社区中非常流行且高效的工作流程：
这种方式结合了 TradingView 的开发效率和 Python 的执行能力，让你两边的优点都能享受到。
TradingView 和 Python 并非是相互排斥的对手，而是在量化交易旅程中处于不同阶段的工具。
作为软件工程师，最好的策略是理解两者的核心权衡：便利性 vs. 灵活性。从 TradingView 开始，当你的需求超出其能力范围时，再自信地投入 Python 的怀抱，甚至可以结合两者，打造出属于你自己的最佳交易系统。
工程师被允许花费他们 20% 的工作时间给任何一个他们自己想要贡献的项目，不用寻求他们经理或者其他人的同意。这非常有价值，因为：
个人和团队都必须公开记录他们的目标和对目标的衡量。
尽管对于重大的新发布的审查是流程化的，但是某个项目该不该做这种问题却没有定论，有些是自下而上的决定，有些是自上而下的决定。
组 的分拆以及合并是家常便饭，似乎这样做能够优化效率。
20% 时间的结果是好的，比如孵化了 Gmail，AdSense 等等举足轻重的项目。在一个跑马圈地的年代，鼓励优秀的工程师花一些时间做一些新东西是非常合算的。在公司还小需要用非常好的福利措施来吸引人才的时候，宣扬 20% 时间也是一种特立独行的手段。我更倾向于 20% 时间是一种管理风格，而不是成功的必然原因。
ORKs 与绩效考核不直接相关，这种区分非常重要 —— 换句话说，就是愿景与执行分离，目标管理与绩效管理分离。举个例子，你开车从 A 点到 B 点，“你有没有到终点？”，对比，“你开的这辆车是不是好车？”，其实是两个不同的问题。同样的道理，产品最后卖的不好，与工程师有没有做出好的产品，是两件不同的事情。
对于普通的工程师来讲，在大公司里面跟其他组，包括跟你具体工作没关系的其他组，保持好的关系很重要，因为这相当于你在劳动力供求的市场上多出了一些需求方。这样一旦发生重组或者其他不利的事件的时候，你能够有更多的选择。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
