一篇关于「AI 大量代写代码之后，自己写代码的能力会弱化，所以要把学习重心上移到框架层」的实践记录。讲四件事：为什么该学的是框架层而不是细节 API、怎么系统学框架、怎么指挥 AI 搭出坚固的架子，以及底座扎实之后 AI 写业务为什么更稳。 一、承认一个不舒服的事实：写的手感会弱化现在我的日常开发，大部分代码不是自己敲的，而是「需求 → 派卡 → AI 写 → 我来验收」。这个流程效率很高，但有一个副作用我观察了很久，也跟不少同行聊过：手写代码的能力，确实在钝化。 具体来说，弱化发生在三个地方： 语法和 API 的记忆在衰减。 以前闭着眼睛能写的 API，现在会习惯性去问 AI；不是不会，是”想不起来”，大脑的检索路径被”问一下就有答案”替代了。 调试直觉在变钝。 以前定位 bug 靠的是对代码的熟悉和手感，现在下意识就是”把报错丢给 AI”。定位问题的肌肉记忆，用进废退。 对代码的”所有权感”在下降。 不是我亲手写的代码，出了问题第一反应是”看看 AI 写的什么”，而不是”我哪写错了”。 但我要先说清楚：对抗这个趋势是徒劳的。 AI 写代码是回不去的方向，回到”全部手写”既不

上一篇《把飞书变成 AI Agent 的日常操作台》拆的是「AI 在飞书里怎么干活」——运行时接入层的架构和踩坑。但那篇文章默认你已经有了一个能对话的机器人。这篇补上前半截：一个不懂代码的普通人，怎么从零开始，把 AI 真正装进飞书。全程网页后台点击 + 一份五层体检脚本，大概 20 分钟能跑通。 一、先说清楚：这件事其实只有两层很多人卡在第一步，是因为把「开通」想象成了一个庞然大物。实际拆开看，把 AI 装进飞书只有两层事： 层 干什么 占的工作量 需要写代码吗 飞书侧开通 在飞书开放平台建应用、开权限、订阅事件、发布版本 约 80% 不需要，全程网页后台点击 agent 侧接入 把 app_id / app_secret 填进你用的 AI agent 配置 约 20% 复制粘贴一段配置 关键点在于：飞书侧这 80% 和你在 agent 侧用什么框架完全无关。你在飞书后台做完所有配置，拿到的唯一产出就是两个值——app_id（形如 cli_xxxxxxxx）和 app_secret。之后不管你是接 Hermes Agent 还是别的任何支持飞书机器人

一篇关于「AI 怎么在聊天软件里成为一个正式角色」的实践拆解。我每天都在飞书里跟我的 AI Agent 协作：发消息派活、在文档里 @ 它改稿、点卡片批准命令。这套体验不是「接了个机器人」，而是一整个平台接入层的设计。这篇文章拆一拆 Hermes Agent（开源）的飞书接入层是怎么做的，以及我用下来踩过的坑和还欠着的优化。 一、为什么要把飞书当 AI 的操作台做 AI 工具的人有个共识：AI 最好长在用户已经在的地方，而不是让用户多开一个工具。 对我来说，那个「已经在的地方」是飞书——上班开着它，手机上也有它，同事、文档、日程全在里面。于是我把自己的 AI Agent 接进了飞书，日常用法就三种： DM 里直接发消息：派活、问问题、传文件，像跟同事聊天一样； 文档里 @ 它：在飞书写完的东西，选中文字评论 @ 一下，AI 读完上下文直接在评论线程里回； 点卡片做决策：AI 要跑危险命令时，发一张「允许一次 / 本次会话 / 总是允许」的卡片，我点一下按钮就完成授权。 体验好的背后是大量看不见的设计。这篇拆的是 Hermes Agent（NousResear

一篇关于「把 MCP 用好」而不是「把 MCP 装好」的实践记录。我在一个车企超级 APP 项目的 iOS 迭代里，用蓝湖（Lanhu）MCP + Lookin MCP 搭了一套项目无关的工具层（harness），把 AI 写代码从「看着截图猜」变成了「读着需求写、对着真机验」。这篇文章讲清楚两件事：MCP 和 harness 到底差在哪一层，以及这套东西是怎么一步步落地的。 一、先分清两件事：MCP 是协议，Harness 是交付形态这两年 MCP（Model Context Protocol）很火，但很多人把它当成万能药：装个 MCP server，AI 就能用了。实际用下来你会发现，MCP 只解决「连接」，不解决「复用」。 我的理解是两层： MCP 层：一种开放协议，让 AI 应用（Claude Code、Cursor、ZCode……）以统一方式调用外部工具。它回答的问题是「AI 怎么连上某个能力」。 Harness 层：在能力之上做一层项目无关的封装——命令行入口、接入模板、提示词模板、产出目录约定。它回答的问题是「这个能力怎么被任何项目、任何 AI 工具顺手用起来」。

一、起因：一个文件夹引发的思考前两天发博客的时候我突然意识到一件事：我这套 Hexo 博客环境，从安装依赖、配置主题、写文章到部署上线，整个流程已经被 AI 跑得很顺了——顺到我自己都快要记不住具体命令了。 然后我就冒出一个想法：既然这套东西对我来说已经是”一键”的，为什么不把它打包出来，让别人也能一键拥有？ 于是有了这个项目：HexoBlogStarter —— 一个开箱即用的 Hexo 博客工具包，内置 Fluid 主题，clone 下来改 3 处配置，10 分钟就能拥有自己的博客。 但它真正有意思的地方不在”又一个 Hexo 模板”，而在于它的设计思路。 二、双通道设计：README 给人看，AGENTS.md 给 AI 看这个仓库里有两份”说明书”： README.md —— 传统的，给人类看的教程：四步上手、目录结构、FAQ AGENTS.md —— 给 AI Agent 看的操作手册：环境怎么装、文章怎么发、故障怎么排查、红线是什么 为什么要专门给 AI 写一份？因为这是我上一篇文章里那个观点的又一次实践：Markdown 正在同时成为人和 AI 的共同语言。 拿到这个

一、先说一个我踩过的坑上个月做一个会员功能，规则是”连续包月用户，取消后已付费周期内权益保留”。规则是在群里聊定的，我（iOS）看完聊天记录的理解是：到期那一刻权益失效。Android 的理解是：取消那一刻还能用到周期末。后端的理解又是另一回事：他返回的字段里压根没有”到期时间”，只有一个”是否有效”的布尔值。 联调那天三方一对，全对不上。翻聊天记录，产品原话是”取消了当然还能用到月底啊”——这句话同时支持我们三个人的三种理解。 最后后端加字段、两端改逻辑，白花了两天。这种事的根源不是谁水平差，而是沟通介质有问题：群聊、语音、口头传达，天然就是模糊的、易丢失的、无法比对的。 而规则类、逻辑类的需求，恰恰是最经不起模糊的东西。 尤其是一个需求涉及 iOS、Android、前端、后端好几个端的时候——同一条产品规则，后端是校验逻辑，前端是交互提示，客户端是本地展示加兜底，每个端的实现方式都不一样。没有一份统一的、精确的参照物，误解是必然，一致才是运气。 二、解法：规则不靠”聊”，靠一份 AI 生成的 Markdown 文档后来我在项目里换了个流程，核心就一句话： 任何涉及规则、逻辑的需求

一、一个正在发生的变化这两年，几乎每个程序员都能明显感觉到：写代码这件事本身，正在变得越来越”便宜”。 以前需要一个下午才能搭出来的 CRUD 接口，现在 AI 几分钟就生成好了；以前要翻半天文档才能搞懂的 API 用法，现在问一句就有答案。代码的”产量”不再是瓶颈，甚至某种程度上，经验带来的”写代码速度优势”正在被 AI 拉平。 一个工作三年的工程师和一个工作十年的工程师，在 AI 的辅助下，产出代码的速度可能差不了太多。 那差距在哪里？ 我的观察是：差距转移到了代码之外的地方。AI 可以生成代码，但它生成的代码对不对、合不合适、上线后会不会出事，仍然需要人来判断和兜底。于是，有三种品质变得比”开发经验”本身更重要了——细心、负责任、肯钻研。 二、细心：AI 时代的核心竞争力是”审稿子”的能力用过 AI 写代码的人都知道一个事实：AI 生成的代码，看起来总是对的。 它语法工整、命名规范、注释齐全，甚至自信满满。但里面可能藏着一个空指针隐患、一个边界条件没处理、一个被”幻觉”出来的不存在的 API。AI 不会为自己的错误心虚，它错得理直气壮。 这就意味着，工程师的工作重心正在从”写代码

前面发了两篇 SOP：公司级迭代开发 和 个人级独立开发。写完发现一个更根本的问题：这些 SOP 是怎么来的？换一个项目，能不能再造一套？ 答案是能——因为我还有一套”生产 SOP 的 SOP”，一个 AI 协作元框架，我叫它 SOP 锻造厂（SOP-Forge）。这篇就讲它。 它解决什么问题用 AI 做项目，三个反复出现的痛： AI 接手项目时两眼一抹黑 — 不知道项目结构、技术栈、坑在哪，每次都是从零开始的实习生 一套 SOP 打天下，水土不服 — 公司项目的流程套到个人项目上，重得跑不动；反过来又太野 经验散落在对话里 — 这个项目踩的坑、验证过的好方案，对话一关就没了，下个项目接着踩 SOP-Forge 的思路：不直接帮 AI 干活，而是给 AI 造一条”接手项目”的流水线。 四阶段流水线12301-Scout 扫描 → 02-TeamForge 角色链 → 03-SOPForge 组装 → 04-Execution 执行 ↓

之前发过一篇《用AI写毕业论文的完整踩坑实录》，讲的是查重、AIGC 检测这些”业务坑”。这篇换个角度：一个完整论文周期跑下来，我对 AI Agent 协作本身学到的几堂课——这些经验不只适用于写论文，做任何 AI 辅助的长周期项目都用得上。 对应的工具箱已开源：github.com/luodeCoding/ai-thesis-writing 第一课：多 Agent 轮流编辑，会互相”回退”论文这种长周期项目，不可能只用一个 AI：这个模型写初稿便宜，那个模型改格式细心。问题来了——后一个 Agent 不知道前一个改了什么，会把它认为”不对”的地方改回去。 真实事故：Agent A 把节点数从代码里核实后改成 11 个；第二天 Agent B 凭”印象”觉得不对，又改回 10 个。 解法：给 Agent 们建”交接班”机制。 12PLAN.md → 唯一权威进度文件（时间线 + 任务清单 + 质量指标）CHANGELOG.md → 每次改动记录（改了什么文件、为什么、依据是什么） 规矩只有一条：任何 Agent 接手前必须先读这两个文件，改完必须更

这个系列的前四个阶段写于 2020 年（环境配置 → 路由管理 → Widget 基础 → ListView）。6 年过去，Flutter 已经从 1.x 迭代到 3.4x，很多东西都变了。这一阶段把「现在的 Flutter」重新梳理一遍。 我机器上的环境：Flutter 3.41.0-pre（master 通道），Dart 3.12。目前稳定版节奏是每年 4 个版本：3.41（2 月）、3.44（5 月）、3.47（8 月）、3.50（11 月）。 一、2026 年 Flutter 的几个大变化1. Material / Cupertino 库正在解耦官方正在把 Material 和 Cupertino 从 SDK 核心拆成独立 package。好处： 设计库不用等季度版 SDK，随时升级 iOS 出 “Liquid Glass”、Android 出 “Material 3 Expressive” 这种大改版时，Flutter 能更快跟上 老项目可以锁 SDK 版本、只升设计包 2. Impeller 渲染引擎成为默认当年iOS 上臭名昭著的「首次动画卡顿」（sh