4 月 17 日，受邀来深圳做一次内部 AI Coding 分享。来之前，我很忐忑，不知它是怎样一座城市，充满好奇与陌生。

在技术分享中，我听到一些有趣观点，颠覆刷新了不少认知。有点无从下手组织语言，等以后有机会再写文章细聊。但我可以先把自己写的 PPT 部分内容分享出来，供大家参考。

lencx 分享

在混乱中，学习，摸索，前行...

AI 趋势 & 判断

AI 迭代太快，我们作为普通人，精力十分有限，追逐热点，到最后可能会发现自己一直在掉队。比如 OpenClaw 年初那会很火，你着急忙慌的让团队去研究，去实现，去部署，结果上线没两天，Hermes Agent 又发布了，你又将陷入新的循环...

还有自媒体在旁边煽风点火，不是程序员死了，就是哪里炸了，不焦虑都难...

判断

关于 AI 趋势的判断，基本都被我设计进 Noi 了。公众号写作的很大一部分原因并不是因为我喜欢分享，学习是主要目的，分享是顺手。我曾在朋友圈写过一段话：写长文太累，那是第三种快乐，写的时候不快乐，写完了也不觉得快乐（不想再写），可能过了很久，发现那些东西沉淀为自己的人生经验了，才觉得快乐吧…

几年前，我也是疯狂追 AI 热点发布文章的一员，后来发现有些资讯实效性高，价值低，讨论度过去也就过去了，但写文章的时间却实打实浪费掉了（实效太短的，连谈资都算不上，还没聊就已经结束了）。所以我开始重新思考写作的意义，不该是为了写而写，应该是为了需要而写。

如果 get 到这层关系，就没那么焦虑了。只需在正确的时间做正确的事，既不掉队，也不盲目跟风。AI 趋势看似很大，其实很小（痛点出现，就会伴随新的解决方案出现）。如果让总结一下此趋势，我认为主要有以下几阶段：

• 应用形态：Chatbot → Agent Framework  → AI IDE/Browser（CDP/CLI）→ Harness
• 记忆需求：Chatbot（单会话短时记忆）→ OpenClaw（跨时间、记忆偏好）→ Hermes Agent（记忆自我进化）
• 工程变化：Prompt Engineering → Context Engineering → Harness Engineering
• 能力复用：MCP → Skills

另一个值得注意点：OpenClaw 的火爆，还带火了一波 CLI 开发热潮。Skills 则是另类爆火，万物皆可 Skill，蒸馏名人、同事的蹭热度 Skill 也很受欢迎...

之前写过《深度解析：Harness Engineering》，如果没太理解，我这里还画了张统一关系图：Prompt ⊂ Context ⊂ Harness；Harness 通过 MCP 接入能力，并加载/调用 Skills；相关结果经 Harness 回注 Context。

趋势

从目前 AI 发展，我看到了哪些趋势：

• GEO：针对 AI 爬虫的搜索引擎优化，在我看来不算重要，但值得做。大模型喜欢结构化数据，那就提供 /llms.txt^[1] 这种标准化的爬取入口，更进一步，让网站具有 agent 操作性，无障碍阅读值得认真对待（据我了解，国内这块普遍做的不好）。
• CLI 化：它并不等于最佳接口形态，但往往是最容易被 Agent 接入的一层能力表面。对于复杂交互，底层仍可能需要 JSON-RPC 2.0、流式通信或分片传输；但从 Agent 编排视角看，CLI 所具备的原子性、可组合性、可观测性与脚本友好性，决定了它常常比纯 GUI 或隐式接口更适合作为执行入口。参考阅读：Agent 趋势浅思：原生化 & CLI 化
• 更大的 Context 需求：理想情况下，整个操作系统都可作为上下文被 AI 访问和理解，但在可预见的未来，Context 的容量仍然是有限的，因此如何高效地管理和利用 Context 将成为关键挑战。
• 连续持久化记忆：从短期会话到长期持久化记忆的转变，将使 AI 能够更好地理解用户的历史行为和偏好，从而提供更个性化和上下文相关的响应。但记忆的更新/遗忘仍是难点，这是一个动态治理问题。参考阅读：Agent Memory 架构本质、知识会长成“壳”，禁锢你
• 统一协议/集成环境：目前 Agent 生态碎片化严重，从 CLI 到 API，从工具调用到记忆管理，再到跨平台沙盒环境，到处都是坑。比如 CLI 不支持流式输出，大数据需要切片喂等等。如何有效组织管理，将是下一个趋势热点，它或许就是 AgentOS（会包含大量环境处理、任务调度等）。
• ...

AI Coding

我这几年精力都放在 AI 桌面应用开发上，对许多人来说，经验不一定适用。和 AI 聊得最多的东西是这些：

把 Agent 系统类比为人体不一定是最佳解，但或许是一种有效理解架构的方式：AI 像高阶认知中枢，工具像感知与执行器官，Harness 更像负责上下文组织、信号传递、行为约束与状态协调的神经—调度系统，而上下文与数据流则类似神经信号、递质与激素在机体内的传播...

Andrej Karpathy Coding 经验

失效工作模式：

• 静默假设：模型经常会替你做出错误假设，并在不加确认的情况下继续推进。它们往往不擅长管理自身的困惑，也不会主动寻求澄清、暴露不一致之处、呈现权衡，或在该提出异议的时候提出异议。
• 输出过度复杂：模型倾向于让代码、抽象层和 API 不断膨胀。除非你明确引导它朝更简单的方案收敛，否则它往往会产出远超实际所需的代码量。
• 连带改动：模型可能会顺手修改或删除与当前任务无关的注释和代码，包括那些它其实并未真正理解的部分；这些改动常常只是无关编辑带来的副作用。
• 缺乏自我清理：模型在实现过程中产生的死代码，往往不会主动清理。
• 讨好倾向：模型很容易过快认同用户，而不是对可疑请求提出质疑，或主动给出更好的替代方案。

有效工作模式：

• 声明式优于命令式：与其给出详细的逐步操作指令，不如直接给出成功标准。当目标被清晰定义后，模型往往更擅长围绕一个可验证的结果持续循环推进。
• 在可行时先写测试：先让模型写测试，再让它把测试跑通。这样能为它提供一个具体、可自我验证的目标。
• 先朴素实现，再优化：先从那个显然正确的版本开始，再在保持正确性的前提下做优化。这样可以降低因为一开始过于“聪明”的实现而引入隐蔽 bug 的风险。

一定要学会自己写 Skills，比如我就根据 AK 大神的分享，自己写了个 coding-protocol：https://github.com/lencx/skills

个人经验

从开发 Noi 中获取到的一些经验：

• Skills 并不是越多越好，多了反而会打架，我自己是没有装过任何 Skills/CLI。
• AI 先写架构文档，再实现代码（这是一句正确的废话）。因为 AI 迭代代码的速度是指数，如果没有文档作为锚点，代码很快就会变成一团乱麻。真正的 AI Coding，需要人要尽可能少的参与细节实现，将人力工作转移到架构设计和规则约束上。一句话：真实业务代码含人量越低越好，这也是 Harness。
• 代码参考，如果需要参考一些开源项目/老项目，可以将其整体作为参考源给到 Codex/CC，比如读取 ../../xxx 目录，开始分析或迁移，而不是把零散的代码片段丢给 AI，来让它帮你写代码。因为 AI 是基于上下文进行分析和生成的，提供完整的项目结构和相关文件，可以让 AI 更好地理解代码的整体架构和逻辑，从而生成更准确和高质量的代码。如果需要反复访问的项目或文件，还可以将其固化进当前项目的架构文档中。
• Electron 是对 AI 最友好的应用框架，尤其是 utilityProcess 在某些 Agent 场景有奇效！更不用说 Chromium + Node.js 能做的事有多少了...
• Electron + React + TailwindCSS，再配合一些原生二进制（比如 better-sqlite3），几乎可以覆盖大部分 Agent 场景，似乎没有比它更全面的框架了。
• 如果需要交互客户端的话选 Electron。否则推荐开发 CLI，Rust 是不错选择，直接打包成单一可执行二进制文件（Bun 也可尝试，毕竟 CC 也在用）。
• Chromium 对应着 CDP 协议，Node.js 对应着 CLI，这就是天然的 Agent 行动场。
• ...

深圳面基

目前在深圳第四天了，和网友粉丝面基成功，大家都十分热情，让我体会到了什么叫“来了就是深圳人，时间就是金钱”！聊的内容很杂，主要包括我对 AI、Agent 趋势的一些判断和产品思考等，因为是口语化的，我可以比文章聊出更多想写没写的东西，感觉这几天把自己几年的话都说完了（给我最深的感受：关注公众号的人，似乎在某些方面都有一些相似性，所以大家都十分聊得来）。

还和网友一起爬了大南山，感觉更像深圳人了，哈哈哈。

接下来可能还会在深圳待几天，如果有想约朋友欢迎私信~，或在公众号发送 “深圳” 进面基群。

References