一、起因：一个文件夹引发的思考前两天发博客的时候我突然意识到一件事：我这套 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

个人独立开发最爽的是没有约束，最惨的也是没有约束——没有产品经理写需求，没有测试验收，没有同事 review，想到哪写到哪。结果就是个人项目的三大死法：架构腐烂、半成品堆积、过两个月自己接手都断片。 这几年我用”一人 + AI 分饰整个团队”的方式做个人项目，沉淀了一套个人级独立开发 SOP，脱敏后开源了： GitHub：github.com/luodeCoding/ios-indie-dev-sop ⭐ 先说结论：个人项目的 SOP 核心不是”流程合规”，而是用最小的文档成本换来三件事——不断片、不腐烂、能验收。 📌 一人 + AI 的完整角色链1RD(需求) → PM(产品) → [合规官] → ARCH(架构) → DEV(开发) → QA(测试) 你出想法，AI 分饰其余所有角色。每个角色的产出都落盘成文档： 角色 产物 门禁（产出前自检） RD {模块}_Draft.md 交互草案 场景分析、页面流程、ASCII 布局图 PM {模块}_PRD.md 功能 P0/P1/P

在多个商业外包 iOS 项目里摸爬滚打了几年，我发现公司级项目最消耗人的不是技术难度，而是流程损耗：需求理解偏差导致返工、多人/人机混编导致规范漂移、测试流于形式、踩过的坑换个项目接着踩。 这几年我把迭代流程逐步标准化，再让 AI 介入每个环节，沉淀成了一套完整的 SOP。最近把它脱敏整理后开源了： GitHub：github.com/luodeCoding/ios-ai-dev-sop ⭐ 先说结论：这套 SOP 的核心不是”流程文档”，而是把流程切成标准阶段、每个阶段配好模板和质量门禁，再让 AI 承担每个环节里可自动化的部分——把”人盯流程”变成”流程盯人”。 📌 五阶段迭代主流程1需求输入 → 架构师分析 → 开发实现 → UI 测试 → 逻辑测试 → 交付 每个阶段都有明确的产出物模板，挑几个最关键的： 架构师分析：最重要的防返工闸门收到需求后三件事，顺序不可颠倒： 需求理解确认 — 必须先读产品文档再动手！产品文档包含业务规则（权限要求、用户类型限制），跳过这步返工率极高 技术方案 — 中/大功能必须写清：改动范围、新增&

最近完整走完了一次”AI 辅助毕业论文”的全流程——从选题到初稿提交，中间踩了无数坑。把这些经验提炼成了一套方法论 + 3 个可直接运行的检测脚本，全部开源了： GitHub：github.com/luodeCoding/ai-thesis-writing ⭐ 先说结论：用 AI 写论文，最大的风险不是”写不出来”，而是写出来之后过不了查重、过不了 AIGC 检测、前后章节数据互相打架。 📌 五个最致命的坑坑1：第2章（相关技术）是查重重灾区AI 生成的技术介绍——“XX是一种基于YY的技术范式”——网上到处都是雷同表述。我的解法：调整写作顺序，先写系统实现（代码现成，查重天然低），最后写技术章节。等你把系统都做完了，这些技术已经消化了，能用自己的话重写。 推荐顺序： 12345678第5章 系统实现 ← 第一个写（最安全）第4章 系统设计第1章 绪论第3章 需求分析第6章 系统测试（跑真实系统）第7章 总结与展望第2章 相关技术 ← 最后写（风险最高）摘要 + 关键词 坑2：论文自己跟自己重复绪论”研究内容”和各章开头天然重复 60-75%，绪论和结论重

🚀 iOS 26/27 适配完全指南：自动化扫描 + 零遗漏总账 + 踩坑实录 TL;DR：4 月 28 日 App Store 强制 iOS 26 SDK，9 月 Xcode 27 强制 Liquid Glass，明年 4 月强制 iOS 27 SDK（未迁 UIScene 直接无法启动）。本文分享一套开源适配方案：Python 扫描脚本（50+ 规则）+ 50 项覆盖总账（AI 适配零遗漏）、Swift/OC 双语言模板、可一键安装到 Claude Code/Qoder 的 AI 技能，承诺只改 iOS 26/27 相关代码、不冲击主项目。GitHub 已开源，可直接用于生产。 📌 为什么写这篇文章上周团队收到苹果邮件：4 月 28 日之后，所有新提交和更新必须使用 iOS 26 SDK 构建。deadline 就在眼前，但网上资料分散，缺乏系统性方案。 于是我们做了两轮深度 QA 排查，整理出了这套开源适配框架。本文把项目背景、扫描工具实现、以及排查过程中发现的坑一次性讲清楚。 GitHub：github.com/luo