前面发了两篇 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

RoForm自定义表单自定义表单工具，简单配置，实现清晰，快速创建表单 效果 如何导入 项目中导入NEFormTableView，UIHelper，Vender等文件夹； pod中有依赖1234567891011pod 'Masonry', '~> 1.1.0'pod 'BRPickerView', '~> 2.7.6'pod 'HCSStarRatingView', '~> 1.5'pod 'QMUIKit', '~> 4.4.0'pod 'ReactiveObjC', '~> 3.1.0'pod 'SDWebImage', '~> 5.0' 库中包含了图片选择所以需要相册相机权限Privacy - Photo Library Usage Description 授权通过相册，选择头像或身份证照片 P

iOS封装CoreData+HandyJson实现本地缓存 准备工作 选中Tagets->BuildPhases->LinkBinaryWithLibraries 添加CoreData.framework 使用CocoaPods工具Pod需要使用的相关框架 pod 'AlecrimCoreData' pod 'HandyJSON', '~> 5.0.1' CoreData基本使用查看上篇博客《CoreData数据持久化》 链接如下：CoreData数据持久化 配置 PersistentContainer 创建PersistentContainer+App.swift 代码如下 import Foundation import AlecrimCoreData extension PersistentContainer { public convenience init(name: String? = nil, bundle: Bundle? = nil) {

CoreData数据持久化 概念 CoreData是Apple官方为iOS提供的一个数据持久化方案，其本质是一个通过封装底层数据操作，让程序员以面向对象的方式存储和管理数据的ORM框架（Object-Relational Mapping：对象-关系映射，简称ORM）。虽然底层支持SQLite、二进制数据、xml等多种文件存储，但是主要还是用来操作SQLite数据库。 NSManagedObjectContext 是托管对象上下文，数据库的大多数操作是在这个类操作 NSManagedObjectModel 是托管对象模型，其中一个托管对象模型关联到一个模型文件，里面存储着数据库的数据结构。 NSPersistentStoreCoordinator 是持久化存储协调器，主要负责协调上下文玉存储的区域的关系。 NSManagedObject 是托管对象类，其中CoreData里面的托管对象都会继承此类。 创建相关文件 两种方式 如果创建项目的时候就勾选了UseCoreData也就会自动生成一个.xcdatamodeld后缀的文件 如果已有项目中就需要手动去创建一个T