登录

范叶亮写智能体、模型和数据系统时，习惯先把定义和边界钉死。把「确定性和掌控欲」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

问题从哪来

最近观察自己和团队在使用 AI 上遇到了一些情况，比如生成的东西（代码、报告、网页等）“虾”味儿比较重，交付质量上也良莠不齐（准确性和深度等方面）。甚至在一些没有必要的场景（至少我认为没有必要）非要把 AI 用上，我想 FOMO 和组织压力是两个重要的“罪魁祸首”。彼时大家考虑更多的是如何“用上” AI，而不是如何“用好” AI。以任何一个角度去切入去尝试 AI 都是对的，欠妥的是当遇到“为什么一会儿行一会不行”，“为什么他那行我这不行”的时候，又会去质疑 AI 不行而不是自己用得不好。

思辨的意义在于过程中的反复，而不是最后的 对与错和好与坏 。在评判 AI 是否应该介入一个工作的时候我会关注两个点：

方法怎么选

一篇 『文科生 72 小时杀入 GitHub 全球榜：我没写一行代码，但指挥了一支 AI 军队』 让“技术平权”再次沸腾，但我希望在团队拥抱 AI 的过程中成为一个仁慈的独裁者 1 2 ，确定性和掌控欲不是阻碍 AI 落地的绊脚石，当个“甩手掌柜”才是加速被淘汰的慢性毒药。

在之前的 文章 中提过 LLM 本身是一个无状态的服务，你给他什么样的输入，它就会预测什么样的输出。产生不确定性的核心在于当今 AI 的背后是一个概率预测模型：

落地时先钉死的事

排除网络架构的不同 3 4 ，即使最朴素的全连接神经网络，在给到足够的训练数据时，其仍可以拟合任意函数：

通过调整如上参数，你可以一定程度上控制 AI 输出的不确定性，当写代码时可以让其更确定些，当做内容创作时可以让其更随机些。用好 AI，而不是当 AI 彻底放飞自我的时候只会吐槽它又变“傻”了。Harness Engineering 也在尝试从应用层解决产出可靠性的问题。

检查清单

在写 Skill 的时候，根据 Claude Code 的 Skill 编写规范 ， SKILL.md 文件应该在 500 行以下，更详细的参考资料应该转移到单独的文件中去。确定性的事情应该放在 scripts 中用代码实现，当下用 AI 写 Skill 的时候虽然它知道利用脚本实现一些确定性的事情，但脚本自身是否正确是否鲁棒你心里还需有个谱。知其然，知其所以然，AI 时代没有要求大家都需要搞明白模型中的各种数学公式，但用好 AI 的人也绝不仅限于知道几个 AI 名词而已。

现在面向代码春暖花开的我曾经学了 7 年的管理，记得管理学老师开堂的第一句话是：管理学既是一门科学，又是一门艺术。科学性在于我们有经典的 马斯洛需求层次理论 和 双因素理论 ，艺术性在于人与社会的复杂和管理实践中“度”的拿捏，例如放权。网上有这样一篇文章： 不懂代码反而是优势，为什么控制欲强的人用不好 AI？ 。我个人的观点是五五开，当前技术发展之迅猛前所未有，不懂代码就不会陷入固有的行为模式中去，确实更容易拥抱变化，但控制欲强并不代表不放权，随着 AI 时代生产力和生产关系的变化 ，放权的艺术也需要与时俱进。

值得单独记下的点

  • ROI：一切抛开成本的使用都是耍流氓。典型的例子就是一个事儿一年都干不了几次，不确定性还很高，想要 AI 帮你一步到位纯纯就是幻想（至少现在是）。
  • 角色：它在这件事儿中扮演什么样的角色。以画图为例（这里说的是思维导图、架构图之类，而非数据图），我可以和 AI 探讨思路，然后把结果按照想要的样子放上去。而不是一句话：帮我把 XXX 画一个架构图出来。图的意义从来不是这张图本身，而是拼拼凑凑形成过程中的思考，当你想一句话画出来的时候，你不想干的一定不是“画”而是“思考”。
  • AI 触发审查机制，尽管我的要求合法合规，但由于给定的上下文背景中存在敏感信息，AI 最终会拒绝我的要求。
  • AI 在授权的场景下，为了实现要求会“不择手段”的尝试尽可能多的路径，但对于路径在物理世界的风险评估不够，有时会造成一些不好的结果。例如：因为现有系统存在 BUG，AI 执行了本不该执行的操作，最后导致原有系统发生崩溃。这锅你说是让 AI 背，还是你来背，还是现有系统背，还是各打五十大板？
  • 摆正思想，善（善良）用 AI ：不为恶（Don’t be Evil）是 Google 提出的企业座右铭，真的很难做到，但我们又必须去做。我的底线可以低些，但不能没有。
  • 摆正角色，善（善于）用 AI ：当下我们需要为 AI 犯下的错误承当全部责任，不要以为你说的三两句指令无关痛痒，一切的后果及其引发的一连串问题你都难以想象。
  • https://zh.wikipedia.org/wiki仁慈独裁 ↩︎
  • https://zh.wikipedia.org/wiki/终身仁慈独裁者 ↩︎

落地时建议先做的 5 件事

  1. 先写清任务能不能被自动验证：能验证的交给系统和评测，不能验证的留给人审。
  2. 本地部署先算显存、延迟和失败回滚，不要只看能跑通一次。
  3. 多智能体只在单智能体触到上下文或专业边界时再拆。
  4. Token、微调和压缩都要有对照数字，避免口号式优化。
  5. 结论写成可检查清单：接口、超时、评测集、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，最该拿走的是「单智能体先做好工具和提示，再谈编排」。数字员工、技能市场和网关应共用同一套评测与权限，而不是各写一套角色人设。

相关文章

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源

常见问题 FAQ

为什么在使用AI时会出现生成内容质量参差不齐的情况？

根据文章，问题主要源于团队过于追求“用上”AI而非“用好”AI。FOMO（错过恐惧）和组织压力导致在没有必要的场景强行使用AI，而忽略了输入质量与AI模型概率预测特性的匹配。当AI输出不稳定时，人们容易质疑AI本身，而不是反思使用方法不当。

如何调整参数来控制AI输出的不确定性？

文章提到，LLM是概率预测模型，通过调整如温度、top_p等参数，可以控制输出的随机性。例如，写代码时降低温度使输出更确定，创作内容时增加随机性以激发创意。关键是理解模型特性，避免在AI放飞时只吐槽它变“傻”。

在落地AI项目时，首先应该钉死哪些关键事项？

根据正文，落地时需先明确任务能否自动验证：能验证的交给系统评测，不能的留给人审。还要计算本地部署的显存、延迟和回滚方案，不要只看单次运行。多智能体应在单智能体触及边界时再拆分，确保资源有效利用。

编写AI Skill时有哪些常见陷阱和检查点？

文章建议，编写Skill时，SKILL.md文件应保持在500行以下，详细参考资料转移。确定性任务用脚本实现，但需确保脚本正确鲁棒。常见陷阱包括过度依赖AI生成脚本而不验证，导致错误难以察觉。知其然且知其所以然，避免只知AI名词。

为什么在使用AI时要重视ROI（投资回报率）？

ROI是关键，因为一切抛开成本的使用都是耍流氓。文章举例：如果某事一年做不了几次，不确定性还高，指望AI一步到位纯属幻想。评估成本与收益，确保AI应用实际有效，避免资源浪费。

如何将AI系统与龙虾PRO/OpenClaw这样的智能体产品集成？

根据文章，集成时应首先做好单智能体的工具和提示，再谈编排。数字员工、技能市场和网口应共用同一套评测与权限系统，避免角色人设分散。龙虾PRO在落地时强调单智能体基础，确保集成可靠。