上个月，Google 和微软两家在各自开发者大会上都发布了新产品，其中 Google 推出了异步编程智能体 “Jules”。第一时间，我便尝试了一下。
作为一名情绪稳定的成年人，咱怎么能那么俗地像那帮 AI KOL 一样大惊小怪地高呼牛逼呢？咱只用它来写点咱没时间或懒得写的代码，跟它的宣传口号一样：
Jules does coding tasks you don’t want to do.
我先后进行了三次尝试，并且严格遵循君子动口不动手的原则。结果是：满意率 1/3。倒是跟 Jeff Dean 在这篇访谈中说的差不多：
我们有一段特别酷的演示：你可以上传一段教育类 YouTube 视频，然后提示词是“请根据这段视频制作一个包含图形和互动元素的教育游戏”。虽然并不总能成功，但有大约 30% 的几率，它确实能生成一些有趣的内容
第一次尝试：工程模板
我一直想把手头的项目总结成一个工程模板方便未来重复使用，因为团队一直也是琐事不断，所以一直也就没有安排人去干。现在 Jules 来了，免费的 ai 小弟，不用白不用。
指定需求和对应的技术栈：
- typescript
- next.js + shadcn + tailwindcss
- drizzle orm + postgresql
- better-auth
- polar
Jules 小弟生成了像模像样的计划，我确认无误后，便批准了。因为当时用的人比较多，我估计它得忙活一段时间，于是便去做别的事了。
大约一个小时后，我回来检查结果，让人大跌眼镜：它还在忙活库安装的问题……那就，再给他点时间。第二天回来检查，貌似完工了，于是乎开始看代码。
一开始，还像模像样，但是到了 better-auth 部分，看到它居然还连带用上了 next-auth！这时，我立马没有兴趣看了，而且也懒得再跟它沟通。一来是当时 Jules 比较慢，二来我找它来是要图省事，不是来给它当老师。
结果：失败并放弃。
非权威原因分析：
- 作为后起之秀的
better-auth和polar可能尚未被广大开发者采纳，正面和反面教材都不够，导致 Jules 无法正确掌握。 - Jules 应该也没有好好看两者的文档，因为两者都提供了可供复制粘贴的代码示例，即使不用 Jules 也能很快上手。
- 初出茅庐，尚需锻炼。
人工介入时间：不足 1 小时。
第二次尝试：image diff 工具
这个需求来自我个人真实需求：图片收集太多了，难免有重复的，人工比对不来。并且这个需求单一，没有太多不同的工具混合使用，同时运行环境的要求也简单：cli 即可。
说干就干，直接给 Jules 下达了指令：
create a cli image diff tool called "image_diff".
the usages:
- image diff fold1 --threshold=xx, list all the images whose similarity >= xx in the folder
notes:
- you should compare the images in a folder in a pairwise way.
- support png and jpg
- use python and transformer
- use local models
- the user can chose which models for use.在 review 它的第一次实现时发现：居然没有用 uv。所以，连代码都没看，就让它加上 uv 支持。
在澄清完此 uv 非彼 uv 后，Jules 便开始了第二次尝试，并顺利完成。
盲测它的代码后发现：虽然可以工作，但太慢了，因为每次相似度都是现算。于是，让它把性能优化一下。
它自行决定方案之后，便开始了第三次尝试：当然是使用 cache。但我试过后，发现效果不佳。最终，给它明确指示：用 lancedb 算了，别每次都算再加缓存。并且，放到 db 中还能以后复用。
这回，效果和性能都满足要求了，于是开始细致测试和阅读代码。
此处略：n 千字，各位可以从这个链接中看到提交历史。
结果：成功。
非权威原因分析：
- 需求单一，且没有太多不同领域的工具。
- 技术要求明确。
- 业务范围在它的甜区：python 和 ai。
人工介入时间：不足半天。
第三次尝试：现有代码库重构
有了成功的经验，再发奇想：既然 Jules 可以全天候的干活，那么直接让它在开发人员下线后去重构代码库，早上开发上线 review 再接受，岂不美哉？！妥妥地免费劳力！
指令发出之后，批准计划，Jules 小哥上线开干了。
此处略 n 万字，只说结论：虽然在面上，如命名和代码组织，貌似不错，但把它的分支拉下来一测，没法跑。
加上当时 Jules 用的人太多，动不动你就得等半天，于是我放弃了，但保留了它的代码分支。
结果：失败。
非权威原因分析：
- 对于现有复杂代码库重构，Jules 还不够成熟，尚需观察。
- 另一个可能原因则是：没有给它提供足够的上下文信息。
- 因为，当时网站太慢，我的出发点也是想看看它到底几斤几两，所以遵循一切从简原则，没太多废话。
人工介入时间：不足半天。
思考
从实验结果来看：未来可期，并且类似工具会越来越多，也越来越成熟。作为开发者，我们也面临一个最近频频被提及的问题：我们会被取代吗？
我个人对此比较乐观：那些具备领导力的开发者并不会被轻易取代。
- 用行话沟通效率最高，ai 小弟听到懂。但你不说，它可能记不起来。这里可体现出开发者和非开发者使用 ai 的差异。
- 把 how 交给 ai，咱们掌控 what 和 why。你没有必要去跟它们较劲谁的编码能力更强。正如同你不会跟汽车赛跑一样，只需要把控方向盘和油门就行了。
- 转变思维模式：在知识的广度上下功夫，在深度上借助 ai 弥补不足。上面的 image diff 工具就是一个例子：
- 如果你不知道用 transformer，ai 也会给出相应的建议，但花的时间肯定会更多。
- 如果你不知道该把 embedding 放到向量数据库，要 ai 自己想出来要花更多的时间。
- 如果你不知道该选择 lancedb，ai 可能会给出一个更重的方案，在基础设施上增加你的成本。
- 如果你不说要用 local model，你可能会泄露你的隐私。面对图片比较需求，无伤大雅。但在其他场景下，结果可能无法接受。
因此，给处于新时代的开发者，我的建议反而不是去刷题和刷算法，浪费时间！你应该做的事是：
- 广泛阅读，建立知识体系，知道什么情况下用什么工具，即定方向。
- 面对具体需求，先思考业务场景，再借助 ai 去讨论具体实现，即定方法。如果不放心，可以找几个 ai 相互印证一下。
- 将方案交给 ai 实现，在 ai 陷入混乱时在干预。
正如你在领导一个 ai 团队，清楚每个 ai 的特点和长处，善用 ai 出奇制胜。这里最关键的反而可能是：
- prompt 的设计能力。
- 了解不同厂家 ai 的特点和长处。
- 业务场景的理解能力。
如此，方能谈笑间樯橹灰飞烟灭，如韩信所言：我用兵，多多益善！