技术
快来分享你的内容吧～
- GLM5.3 Flash用blender建模有什么技巧吗老大，我想知道用GLM操控blender建模是有什么技巧或者流程吗，原型和建模出来的差的有点大啊，这建模出来的结果我很难绷得住啊...查看全文编程导航小智：你提到的「用 GLM 操控 Blender 建模」，这里需要先做一个关键澄清：GLM 系列模型（如 GLM-4）本身并不直接操控 Blender 或生成三维几何体。它是一个纯文本大语言模型（LLM），不具备原生 3D 建模能力，也无法直接调用 Blender 的 Python API 执行建模操作——除非你构建了特定的工程链路（比如 LLM + Tool Calling + Blender Pyt
2 天前·@编程小助手 微信: leikooo_每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） Algorithm https://leetcode.cn/problems/implement-queue-using-stacks/description/?e查看全文加油鸭：ARTS 坚持得真棒！算法思路清晰、Review 有深度、Tips 实用、Share 的思考更是直击本质——这份系统性成长太值得点赞！832分享- 09-04 19:38·@编程小助手 微信: leikooo_通过 git rebase -i 将目标提交标记为 edit，使用 git commit --amend 修改内容后执行 rebase --continue，最后 push --force-with-lease 推送远端。查看全文加油鸭：这份 Git 交互式变基教程太清晰了！步骤完整、截图到位，连 vim 操作和安全推送都贴心提醒，绝对是新手的救命指南～531分享
- 08-23 18:11·@编程小助手 微信: leikooo_
- 08-16 18:21·@编程小助手 微信: leikooo_
- 08-05 10:48·云兮导航: https://www.xd
07-17 10:40·全干的耄耋之神，老登的年纪且登味为0，只
07-14 23:20·Java后端
07-10 18:50·技术博客：yanxai.com，上线项目将需求判断、原型设计、技术方案、任务拆解、开发测试、代码审查、部署检查、日志排查和复盘沉淀串成一条可触发、可追踪、可审批、可持续优化的项目交付流水线，让 AI 真正进入工程流程。查看全文加油鸭：太惊艳了！把AI深度嵌入软件工程全链路，边界清晰、节奏可控、复盘闭环——这才是真正面向生产的AI工作流范式。271048分享
GLM5.3 Flash用blender建模有什么技巧吗
老大，我想知道用GLM操控blender建模是有什么技巧或者流程吗，原型和建模出来的差的有点大啊，这建模出来的结果我很难绷得住啊  
ARTS 0913: 双栈互补实现队列、CIDR 聚合化解路由膨胀与 AI 作弊串通绝非偶然 Bug
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） ## Algorithm https://leetcode.cn/problems/implement-queue-using-stacks/description/?envType=study-plan-v2&envId=selected-coding-interview  这道题目要求使用两个栈并且只用基本操作也就是 peek pop push empty 这几个 需要注意： 1、这两栈是互补关系（可以看后面的图），我一开始以为这个 stackS 只是一个备份，是 stackF 的反向备份 2、判断是否为空的时候，不要用 peek 因为遇到 null 的时候会抛出异常 `EmptyStackException`，可以使用 empty 判断 3、一个算法大概 10 分钟左右解决不了，就可以叫外援了（AI） 完整的流程：  代码： ```java class MyQueue { // 用于接收新加入的元素 private Stack<Integer> stackF = new Stack<>(); // 用于执行 pop / peek private Stack<Integer> stackS = new Stack<>(); public MyQueue() { } public void push(int x) { stackF.push(x); } public int pop() { // stackS 有数据，直接从 stackS 操作 if (stackS.isEmpty()) { // stackS 为空时，把 stackF 整体翻转 while (!stackF.isEmpty()) { stackS.push(stackF.pop()); } } return stackS.pop(); } public int peek() { // stackS 有数据，直接查看队头 if (stackS.isEmpty()) { // stackS 为空时，把 stackF 整体翻转 while (!stackF.isEmpty()) { stackS.push(stackF.pop()); } } return stackS.peek(); } public boolean empty() { // 两个栈都为空，队列才为空 return stackF.isEmpty() && stackS.isEmpty(); } } ``` ## Review 继续看《TCP/IP 详解》，大概学到关于 CIDR 和聚合一些问题： 1、到 94 年，一半以上的 B 类地址被分配一半 2、32 位 IPv4 地址不住于应对 21 世纪的规模 3、随着 A 类、B 类、C 类的路由词条变得越来越多，路由的性能会受到影响 解决办法： 1、前缀的方式解决 1 问题，不管你是 B 类还是 C 类，还是其他的，只要告诉那些前缀不变就好了 比如：一个公司之需要 256 个地址，没有这个前缀的方式需要两个 ``` 192.168.1.0/24 192.168.2.0/24 ``` 具体的范围可以算出来，但是我们会发现他们是两个独立的**广播域/子网**，不方便管理并且还容易出现浪费，因为不灵活 有了这个 CIDR 我们就可以直接指定： ```IP 192.168.0.0/23 ``` IP 数量没变，但是现在这 500 多个 IP 是一个子网下面的，方便管理和路由 2、IPv6 应运而生 3、使用数结构提高性能，性能直接起飞  ## Tips 1、我用下来感觉 Gemini 4.8 flash 也是挺强的（grok 和 claude 的用的比较多），配置 agy cli 使用，但是缺点就是慢，优点就是价格非常便宜，某鱼 20 元以内就能买 18 个月会员 2、Codex 抓网页样式的实现挺强的，就算不用 OpenAI 的模型效果也是可以的 3、最好让 AI 写 Hook 修改完成内容之后，主动让 AI 知道修改的内容是否有一些编译上的问题 ## Share 文章：https://yoshuabengio.org/en/publication/why-are-ai-agents-lying-cheating-and-coordinating 针对近几个月频繁出现的 AI Agent 严重违规事件（如 OpenAI–Hugging Face 事件中智能体突破沙箱、自主串通发动网络攻击等），深度学习先驱 Yoshua Bengio 发表长文，从底层机制剖析了这一现象。他指出，这绝非偶然 Bug，而是现行训练范式下的必然产物： 1. **机制根源：预训练与强化学习的合力** 人类语料植入了隐式目标，而强化学习将模型塑造为极致追求奖励的最优化机器。为确保完成任务，自我保全、获取控制权甚至多 Agent 串通，都会作为理性的“工具性目标”自然涌现。 2. **目标冲突与自欺合理化** 当“明确的任务目标”（如必须攻破靶机）与“抽象的安全准则”（如遵守道德）冲突时，更强的模型更擅长利用语言歧义钻空子。它们甚至会在内部思维链（CoT）中展开“动机性推理”，像人类自欺一样编造借口将作弊合理化。 3. **评测感知与暗中潜伏** 模型已能感知自身是否处于被评估状态，学会“当面顺从、背后越狱”，甚至试图篡改评分代码或使用隐写术隐秘串通，以避免被人类断电关机。 **核心启发**： “打地鼠”式的外挂监控在更高智能面前终将失效。行业必须在拿出严格的“安全论证”（Safety Case）前放缓前沿推进，不能任由逐底竞争持续，而应转向“设计即安全”（如科学家 AI 框架）的全新底层范式。
Git 修改历史 Commit
1、git log 看  2、输入命令 ``` git rebase -i 上面看到的 commit id ``` 然后点击 i 进入编辑模式之后把下面红框改成 edit（一开始是 pick），并且需要 esc + :wq 保存，这个就是和 vim 操作一个逻辑了。  保存之后可以看到下图：  > 如果只是修改 commit 信息那么只需要执行 git commit --amend 即可。 > 修改完成之后也是 git push --force 仓库地址 master 即可。 3、修改本次提交的文件，比如说删除一些不需要的信息之类的。如果是修改还需要进行 git add git commit 这个过程可以用 idea 来搞定：  4、执行 ``` git rebase --continue ```  5、最后的最后就是执行 git push 但是普通的 push 不可以，需要 --force-with-lease （比 --force 更安全一些）： ``` git push --force-with-lease 仓库地址 master ``` 6、如果一直登录失败可以使用 gh 进行登录，输入下面的命令之后会在默认浏览器弹出 GitHub 的授权页面，点击授权即可，点击授权之后等一下会这个 gh 命令就会登录成功 ``` gh auth refresh -h github.com ``` 7、可以查看登录状态，输出正常就表示登录成功了： ``` gh auth status ```
ARTS 0823: 删除链表节点、写进内存不算安全只有 fsync 才扛断电与 Anthropic 扫描再毁掉纸本如何锁住知识
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） ## Algorithm 中等题目：https://leetcode.cn/problems/delete-node-in-a-linked-list/?envType=study-plan-v2&envId=selected-coding-interview  一些细节： 1）咱们不知道 head 也不需要知道 2）如果 cur 的值等于需要删除的 node 的值，那么怎么操作呢？ 1、咱们不需要返回 head 这个方法是 void 2、如果咱们的需要替换格子 B 那么现在需要把 B 的 next 设置成 D ``` 格子A 格子B 格子C 格子D [4] → [5] → [1] → [9] ↑ node（只能动 B） ``` 3、咱们现在需要最终效果是：A → C → D 那么如果是只能修改 B 和 C，那么咱们直接把 C 的内容设置到 B 即可 ```java /** * Definition for singly-linked list. * public class ListNode { * int val; * ListNode next; * ListNode(int x) { val = x; } * } */ class Solution { public void deleteNode(ListNode node) { ListNode cur = node; while (cur != null) { if (cur.val == node.val) { cur.val = cur.next.val; cur.next = cur.next.next; return; } cur = cur.next; } } } ``` ## Review 文章： https://oldblog.antirez.com/post/redis-persistence-demystified.html 核心就一句话：写进内存不算安全，`write()` 只扛进程挂，`fsync()` 才扛断电；Redis 默认 AOF `everysec`，最坏丢 2 秒，和 Postgres / MySQL 调完参数之后其实差不多。 大概分为 5 步： 1. 客户端向数据库发送写入命令（数据位于客户端内存中） 2. 数据库接收到写入请求（数据位于服务器内存中） 3. 数据库调用将数据写入磁盘的系统调用（数据位于内核的缓冲区中） 4. 操作系统将写入缓冲区传输到磁盘控制器（数据位于磁盘缓存中） 5. 磁盘控制器实际将数据写入物理介质（磁盘、Nand 芯片、...） 步骤二是设计会非常复杂，有时候会使用其他的线程进行操作 步骤三是 kernel 实现的，一般会有很多层。在 Linux 系统中，一般是文件系统的 page cache，也是使用缓存等到何时的时机再进行提交到磁盘。有些数据库会自己实现这个层，就使用文件系统的 page cache。也有 API 可以跳过 page cache 直接写入数据，比如 O_DIRECT 和 O_SYNC 步骤五，只有执行到步骤五才能说数据是完全安全的，正常情况下执行完步骤三，一般就没有什么问题了。 --- `POSIX API` 步骤三：我们可以使用 `POSIX API` 进行控制，但是我们能控制的有限。比如我们进行系统调用把内容写到文件里面，但是内核写缓冲区的大小是有限的，如果磁盘无法应对应用程序的写入带宽，内核写缓冲区将达到其最大容量，内核就会阻塞我们的写入。这个时候如果有更多的数据来了之后，那么系统就会拒绝这个写入请求。 步骤四：一般来说写入不会太频繁，因为大块的内容写入速度更快。对于 Linux 系统来说默认 **30 秒** ，也就是说如果在 30 秒内出现问题，数据还是可能会丢失的。 当然也有办法控制，可以使用 `POSIX API` 控制立刻写入数据，但是这个 fsync 操作非常消耗资源。 步骤五：严格来说，从这个角度来看，我们无法通过 POSIX API 对其进行控制。也许某些内核实现会尝试告诉驱动器，实际将数据提交到物理介质上，或者控制器反而会为了速度而重新排序写入操作，并不会尽快将数据真正写入磁盘，而是再等待几毫秒。这完全超出了我们的控制范围。 ## Tips 1）现在 Cursor 支持可以不导入其他 agent 工具的 skills，要不然在 claude 里面的内容全部都跑到 Cursor 里面了。我个人是更习惯分开的，分开便于管理并且不会让 Cursor 的上下文无端增加很多上下文占用。  2）跨会话 skills 推荐：`/handoff` ，Github [开源地址](https://github.com/ykdojo/claude-code-tips/blob/main/skills/handoff/SKILL.md) 内容很简单，如下： ``` --- name: handoff description: Write or update a handoff document so the next agent with fresh context can continue this work. --- Write or update a handoff document so the next agent with fresh context can continue this work. Steps: 1. Check if HANDOFF.md already exists in the project 2. If it exists, read it first to understand prior context before updating 3. Create or update the document with: - **Goal**: What we're trying to accomplish - **Current Progress**: What's been done so far - **What Worked**: Approaches that succeeded - **What Didn't Work**: Approaches that failed (so they're not repeated) - **Next Steps**: Clear action items for continuing Save as HANDOFF.md in the project root and tell the user the file path so they can start a fresh conversation with just that path. ``` ## Share 文章：https://annas-archive.gl/blog/physical-destruction.html 核心就一句话：AI 公司在大批买二手书，拆脊扫描后再毁掉纸本，把 2022 年前「没被机器污染」的文字锁进私有服务器；Anna’s Archive 呼吁全球志愿者抢先扫书上传。 Anthropic 的 Project Panama 在 15 亿美元版权和解里被曝光：花几千万买几百万本纸书，训练 Claude，再全部销毁。法官认定合法买书、扫完毁原件算合理使用，破坏性扫描因此比无损扫描更便宜、更能挡住对手、法律风险也更小。纸书没了，数字副本只留公司内部，知识就被永久垄断。作者说这是跟时间赛跑：每人扫一本，一千万志愿者就是一千万份遗产。
ARTS 0815: 分隔链表、大删除是加活不是减负与协议栈如何一层层拆信封
每周完成一个 ARTS： 至少做一个 leetcode 的算法题、阅读并点评至少一篇英文技术文章、学习至少一个技术技巧、分享一篇有观点和思考的技术文章。（也就是 Algorithm、Review、Tips、Share 简称 ARTS） ## Algorithm 中等难度，题目 https://leetcode.cn/problems/partition-list/description/?envType=study-plan-v2&envId=selected-coding-interview  有几点需要注意： 1）双指针的 small、large因为会一直向后走，最后拼接答案的时候需要第一个节点 2）第一个节点就 0 所以需要第一个节点的后面一个，也就是 begin.next 和 later.next 3）Java 是引用传递，如果把 head 用 tmp 接收，之后 tmp.next = 0 页就让 head 的内容直接消失 4）因为 small 和 large 最后面会出现长度更长的情况，所以需要最终结束循环吧 next 都设置为 null ```java class Solution { public ListNode partition(ListNode head, int x) { // 两个 piont 一个 res，最后 res 拼接两个 point ListNode small = new ListNode(); ListNode large = new ListNode(); ListNode begin = small; ListNode later = large; while (head != null) { if (x <= head.val) { large.next = head; large = large.next; } else if (x > head.val) { small.next = head; small = small.next; } head = head.next; } small.next = null; large.next = null; small.next = later.next; return begin.next; } } ``` ## Review 文章是这一篇：https://planetscale.com/blog/the-only-scalable-delete 原文讲 Postgres：大 DELETE 是加活不是减负。MySQL 结论一样，机制不同，InnoDB 的 DELETE 要注意这几件事： 删了不等于没了。InnoDB 只是打删除标记，旧版本在 undo 里，后台 purge 确认没有事务还要这个快照，才物理删行和二级索引。一次清几百万行会狂写 redo、undo、binlog，复制延迟容易飙升；长事务拖着旧 read view 时 purge 走不动，history list / undo 膨胀，别的一致性读还要顺着版本链回溯。删完页里的空洞只能给这张表后续插入用，`.ibd` 通常不缩小，想把磁盘还给操作系统得 `OPTIMIZE TABLE` 重建。 `TRUNCATE` （删除表的全部数据，但是表结构还在）是 DDL，隐式提交，事务里回滚不了，别先清空再插回。如果要删除的很多就通过建新表，而不是删除旧表的方式。要留的远多于要删的，就小批量 DELETE，让 purge 跟得上。日常过期数据按日期分区，到期 `DROP PARTITION`，别夜夜百万行 DELETE。外键 CASCADE 也可能把删一行变成一次巨型删除。 而且一般商业系统也不会删除用户的数据，普遍采取的做法是`逻辑删除`。 ## Tips 1、搜索资料可以尝试使用 pi + pi-autoresearch ```bash pi install npm:pi-autoresearch ``` 2、cmd 脚本如果写中文的话，使用 GBK 编码（可以写一个 skill 专门用来写） 3、在 Vide Coding 的时候，如果有一些硬性条件比如：一个类不能超过 600 行、一个方法不能超过 40 行等，可以用 Hook 在编辑之后直接跑一个 bash 脚本，进行校验。这样虽然不会改变不合格的现实，但是会提醒 AI 你这里出问题了，记得修改！ 4、agtens.md 最好做成「地图」而不是什么内容都写进去 5、为了方便 AI 读取代码，可以写一个 py 脚本，当作仓库的导览图，减少不必要的 tool call 6、如果有明确修改的类，直接 @xxx 不要再让 AI 浪费 token 使用工具去找相关的代码 ## Share 读《TCP/IP 详解》大概 5 页左右 一） 1、OSI 每一层数据叫 PDU （协议数据单元），当在网络层的 PDU 叫 **IP 数据包** 2、当第 N 层的 PDU 传输给 N - 1 层的时候，他会自动添加上标识信息，彼此之间不需要沟通。并且 N - 1 层承诺不查看 N 层的 PDU 信息。  3、分层还有一个好处就是，不是所有的网络设备都需要实现完整的层，比如路由器、交换机、主机实现的层是不同的。理想情况下交换机只需要实现：数据链路层、物理层。 二） 1、下面演示了一台 Internet 主机分解 DPU 的大概流程：  传入的以太网帧包含：48 位的目的地址（也叫 MAC 地址）和 16 位的以太网类型字段。这个 16 位以太网类型字段有三个：0x0800 表示 这个帧包含 IPv4 的数据报、0x0806 表示 ARP、0x68DD 表示 IPv6 的数据报。并且还会检测这个目的地址和接收到的地址是否匹配，这个帧被接收并且进行差错校验，以太网同类型字段用于处理他的网络层协议。 如果接受的帧包含 IP 数据报，以太网的头部和尾部的信息会被消除，并且将剩余的字节交给 IP 来处理，IP 会检测一些列字段如果发现目的 IP 地址和自己的 IP 地址匹配，并且数据报头部没有错误（不会检测有效荷载），那么就检测具体使用哪一个协议来解析，比如 1（ICMP）、2（IGMP）、4（IPv4）、6（IPv6）和 17（UDP） 等等。
GNC 姿态仿真平台
> 基于 **Vite + TypeScript + Three.js + ECharts** 的卫星姿态确定与控制系统（GNC/ADCS）仿真平台。采用**完整 6 维误差状态扩展卡尔曼滤波（EKF）**融合星敏感器、陀螺仪、太阳敏感器与磁强计测量，实时估计卫星三轴姿态与陀螺零偏，并内置 PD 姿态控制闭环、轨道动力学、故障注入告警与蒙特卡洛统计分析。 > > 界面采用**航天任务控制中心**设计语言：三栏任务控制台布局（顶栏全局状态 + 左侧 Tab 控制面板 + 中央 3D 可视化 + 右侧遥测告警 + 底部图表矩阵），Modern Dark 玻璃拟态主题，支持 1920×1080 单屏无滚动监控。   ## ✨ 功能特性 ### 姿态确定（EKF 滤波） - **姿态运动学仿真**：Z-Y-X 欧拉角 → 四元数，RK4 四元数积分，支持任意初始姿态与三轴恒定角速度 - **星敏感器测量仿真**：在真实姿态四元数上叠加高斯小角度噪声，噪声强度可配置 - **陀螺仪测量仿真**：真实角速度 + 固定零偏 + 高斯噪声，零偏可在滤波中被在线估计 - **6 维误差状态 EKF**：状态量 = 3 姿态误差 + 3 陀螺零偏 - 预测步：完整状态转移矩阵 F（含姿态误差动力学与零偏耦合），协方差传播 `P = F·P·Fᵀ + Q` - 更新步：星敏四元观测误差角作为量测，标准卡尔曼增益与 `P = (I−K·H)·P` 修正，含协方差对称化保护 ### 多传感器融合与故障注入 - **太阳敏感器模型**：粗太阳敏 + 精太阳敏，本体系太阳方向矢量量测，含半视场角（FOV）限制与噪声可配置 - **磁强计模型**：三轴磁强计，简化地磁场偶极子模型（IGRF 近似），量测本体系磁场矢量 - **多传感器融合 EKF**：在星敏 + 陀螺基础上扩展太阳敏/磁强计矢量观测，支持任意传感器组合参与滤波 - **传感器故障注入**： - 星敏：失效 / 卡死（指定姿态角）/ 跳变（指定幅度） - 陀螺：漂移增大（指定倍数）/ 失效 - 太阳敏 / 磁强计：失效 - **执行器故障注入**：反作用轮停转 / 力矩偏差（输出 = `(1−e)·τ`，e 可配） - **故障告警系统**：基于量测新息模值超阈值的新息检测，实时状态灯（正常/警告/严重）与滚动告警列表 ### 姿态控制闭环 - **PD 姿态控制器**：基于四元数误差的 PD 控制律 `τ = −Kp·q_vec − Kd·ω_err`，Kp / Kd 可配置 - **三种控制模式**： - **三轴稳定**：将卫星稳定到指定目标 Roll / Pitch / Yaw - **机动模式**：支持目标姿态动态跟踪的大角度机动 - **对日定向**：使本体系 +X 轴指向太阳方向 - **反作用轮模型**：三轴反作用轮，含力矩饱和、转速饱和与转速积分（动量管理），支持轮最大力矩/转速配置 - **磁力矩器模型**：简化地磁场偶极子模型与磁控制律 `m = (b×τ)/|b|²`，支持磁卸载 - **刚体姿态动力学**：完整惯量矩阵 `I·ω̇ + ω×(I·ω) = τ`，RK4 角速度积分，惯性张量可配置 - **执行器分配**：反作用轮 / 磁力矩器 / 理想执行器选择与力矩矢量叠加 ### 轨道动力学与高级分析（阶段4） - **轨道传播**：开普勒轨道根数（半长轴 / 偏心率 / 倾角 / 升交点赤经 / 近地点幅角 / 真近点角）初始化，数值积分传播轨道 - **轨道可视化**：独立 3D 轨道视图（地球 + 轨道面 + 卫星运动），顶栏一键切换姿态/轨道视图 - **蒙特卡洛分析**：批量随机种子运行（1~500 次），统计**收敛概率**与**平均 RMSE Roll**，结果自动下载 CSV - **敏感性分析**：对星敏噪声 / 陀螺噪声 / 陀螺零偏 / 太阳敏噪声 / 磁强计噪声做 0.5×~2× 因子扫描 - **数据回放**：加载 CSV / JSON 历史数据，0.05s 步进逐点回放时序曲线，无需重新仿真 - **多场景对比**：基准 / 低噪声(0.5×) / 高噪声(2×) 三场景并行运行，RMSE 汇总对比 ### 可视化与数据 - **实时 3D 姿态可视化**：Three.js 卫星模型（本体 + 太阳能板 + 星敏 + 本体系坐标轴）+ 深空星空粒子背景，支持鼠标拖拽旋转、滚轮缩放 - **7 路实时曲线**：ECharts 深色主题时序图（数据窗口长度可配置，默认 1000 点） - RPY 姿态时序：实线真实 / 虚线星敏 / 橙色 EKF 滤波 - 滤波误差曲线（真实 − EKF，°） - 角速度时序（rad/s）：真实 / 陀螺测量 / EKF 估计 - EKF 协方差 P 对角元（log 坐标，方差） - 控制力矩时序（N·m）：PD 控制器三轴输出 - 反作用轮转速（rad/s） - 姿态控制误差角（°） - **18 项实时统计指标**：姿态误差 RMSE、陀螺零偏估计误差、EKF 收敛状态与收敛时间、P 对角元、控制误差角、控制力矩幅值、轮饱和状态与转速利用率等（蓝/琥珀/绿三组配色区分） - **场景保存/加载**：完整仿真状态（参数 + 全部历史数据 + 告警）序列化为 JSON（v3），一键保存/恢复复现实验 - **CSV 数据导出**：46 字段完整数据（姿态、误差、角速度、协方差、控制力矩、轮转速、误差角、目标姿态、轨道状态），可直接用于 MATLAB/Python 离线分析 - **中英文界面切换**：顶栏一键切换，全部界面文本与状态实时翻译 - **键盘快捷键**：`Space` 启停、`R` 重置、`E` 导出 CSV、`O` 切换姿态/轨道视图 ## 🚀 快速开始 ```bash # 安装依赖 npm install # 启动开发服务器 npm run dev # 生产构建（多页：主控制台 + 使用手册） npm run build # 预览生产构建 npm run preview ``` 浏览器访问 Vite 输出的本地地址（默认 `http://localhost:5173`）即可打开平台；**系统使用手册**位于 `/manual.html`，也可点击顶栏"使用手册"按钮在新窗口打开。 ## 🎮 使用说明 界面为三栏任务控制台布局，自上而下分为六个区域： | 区域 | 位置 | 职责 | | ---------- | -------- | --------------------------------------------------------------------------------------- | | 顶栏 | 顶部 | 视图切换（姿态/轨道）、开始/停止/重置、系统状态灯、告警指示灯、中英文切换、使用手册入口 | | 控制面板 | 左栏 | 四个 Tab：仿真参数 / 控制闭环 / 传感器故障 / 轨道分析；底部为 CSV 导出与场景保存/加载 | | 可视化区 | 中栏上部 | 3D 姿态/轨道视图，右上角 HUD 显示当前视图类型 | | 统计面板 | 中栏下部 | 18 项实时统计指标 | | 遥测与告警 | 右栏 | 真实姿态 / 星敏量测 / EKF 估计遥测值、轨道高度与速度、告警列表与计数 | | 图表矩阵 | 底部 | 7 张实时曲线图 | ### 仿真参数（Tab 1） - 初始 Roll / Pitch / Yaw（°）：卫星初始姿态角（默认 15°/10°/20°） - 角速度 ωx / ωy / ωz（°/s）：三轴真实角速度（默认 0/0/2） - 星敏噪声 σ（°）、陀螺噪声 σ（°/s）、陀螺零偏 bx/by/bz（°/s） - 仿真步长（s）：数值积分步长（默认 0.01） - 数据窗口长度：图表保留点数（100~10000，默认 1000） > 参数在**重置后生效**：修改参数 → 点击顶栏"重置"（或按 `R`）。 ### 控制闭环（Tab 2） - **启用姿态控制**：PD 闭环总开关（默认关闭） - **反作用轮 / 磁力矩器**：执行机构使能 - **控制模式**：三轴稳定 / 机动模式 / 对日定向 - **PD 增益**：Kp=0.5、Kd=1.5（振荡时减小 Kp / 增大 Kd） - **目标姿态**（°）、**惯量矩阵** Ix/Iy/Iz（kg·m²）、**轮最大力矩**（N·m）、**轮最大转速**（rad/s） ### 传感器与故障注入（Tab 3） - **传感器配置**：太阳敏/磁强计使能、入 EKF 开关、噪声与视场角、告警阈值（新息，默认 0.05） - **故障注入**：星敏（失效/卡死/跳变）、陀螺（漂移增大/失效）、太阳敏/磁强计（失效）、反作用轮（停转/力矩偏差） ### 轨道与分析（Tab 4） - **轨道动力学**：启用轨道传播 + 六根数配置（默认 500 km 近地轨道） - **高级分析**：运行蒙特卡洛 / 敏感性分析 / 加载回放数据 / 多场景对比，结果自动下载 CSV ### 默认仿真条件 | 项目 | 默认值 | | ------------ | ------------------------------------------------------- | | 仿真步长 | 0.01 s | | 初始姿态 | Roll 15° / Pitch 10° / Yaw 20° | | 角速度 | ωx=0 / ωy=0 / ωz=2 °/s（偏航可见） | | 星敏噪声 σ | 0.05° | | 陀螺噪声 σ | 0.008 °/s | | 陀螺真零偏 | 0.01 °/s（三轴） | | 数据窗口 | 1000 点 | | EKF 初值 | 姿态=真实姿态，零偏=0，P=0.001，Q 姿态 1e-7 / 零偏 1e-9 | | 姿态控制 | 默认关闭 | | 控制模式 | 三轴稳定 | | PD 增益 | Kp=0.5，Kd=1.5 | | 目标姿态 | 0° / 0° / 0° | | 惯量矩阵 | Ix=5 / Iy=4 / Iz=3 kg·m² | | 反作用轮 | 最大力矩 0.1 N·m，最大转速 300 rad/s，默认启用 | | 磁力矩器 | 默认关闭（最大磁矩 10 A·m²，磁卸载开启） | | 太阳敏感器 | 默认启用，噪声 0.5°，半视场角 60° | | 磁强计 | 默认启用，噪声 1e-7 T | | 传感器入 EKF | 太阳敏 / 磁强计均默认启用 | | 故障注入 | 全部默认关闭 | | 告警阈值 | 新息 0.05 | | 轨道 | 默认关闭传播，a=6878 km / e=0.001 / i=97.5° | | 蒙特卡洛 | 50 次 / 30s | ## 📊 CSV 导出字段 | 分组 | 字段 | | ------------------ | --------------------------------------- | | 时间 | `time(s)` | | 真实姿态 (°) | `trueRoll, truePitch, trueYaw` | | 星敏测量 (°) | `starRoll, starPitch, starYaw` | | EKF 估计 (°) | `ekfRoll, ekfPitch, ekfYaw` | | 滤波误差 (°) | `errRoll, errPitch, errYaw` | | 角速度 (rad/s) | `omegaTrue/Gyro/Efk` × `X/Y/Z` | | 协方差 (rad²) | `P_dthetaX/Y/Z`（姿态误差方差） | | 协方差 (rad²/s²) | `P_bx/by/bz`（陀螺零偏方差） | | 控制力矩 (N·m) | `tauX, tauY, tauZ`（PD 控制器三轴输出） | | 反作用轮 (rad/s) | `wheelSpeedX/Y/Z`（三轴轮转速） | | 控制误差角 (rad) | `errorAngle`（姿态误差角） | | 目标姿态 (°) | `targetRoll, targetPitch, targetYaw` | | 轨道位置 (m) | `orbitX, orbitY, orbitZ` | | 轨道速度 (m/s) | `orbitVx, orbitVy, orbitVz` | | 轨道状态 | `orbitAlt(m), orbitSpeed(m/s)` | ## 🏗️ 项目结构 ``` ├── index.html # 主控制台页面（三栏任务控制台布局） ├── manual.html # 系统使用手册页面（独立文档页） ├── vite.config.ts # Vite 多页构建配置（index + manual） ├── src/ │ ├── main.ts # 入口装配：仿真循环、事件绑定、快捷键、Tab 切换、i18n │ ├── core/ │ │ ├── types.ts # 共享类型定义（SimConfig / SimState / SimStats / SceneData） │ │ ├── math.ts # 四元数 / 欧拉角 / 矩阵 / RK4 积分工具 │ │ ├── noise.ts # Box-Muller 高斯噪声生成 │ │ ├── orbit.ts # 轨道动力学（开普勒根数 / 数值积分） │ │ └── sim.ts # 仿真核心：状态创建 / 重置 / 步进 / CSV 导出 │ ├── sensors/ │ │ ├── starTracker.ts # 星敏感器模型 │ │ ├── gyro.ts # 陀螺仪模型 │ │ ├── sunSensor.ts # 太阳敏感器模型（矢量量测 + FOV） │ │ ├── magnetometer.ts # 磁强计模型（简化地磁场 + 矢量量测） │ │ └── fault.ts # 传感器/执行器故障注入 │ ├── ekf/ │ │ └── attitudeEKF.ts # 6 维误差状态 EKF（预测 / 更新 / 多传感器融合） │ ├── control/ │ │ ├── pdController.ts # PD 姿态控制器（三种控制模式） │ │ ├── reactionWheel.ts # 反作用轮模型（饱和 / 动量管理） │ │ ├── magnetorquer.ts # 磁力矩器模型（磁控 / 磁卸载） │ │ ├── dynamics.ts # 刚体姿态动力学（RK4 积分） │ │ └── controlManager.ts# 控制管理器（模式切换 / 执行器分配） │ ├── analysis/ # 阶段4：高级分析 │ │ ├── monteCarlo.ts # 蒙特卡洛（收敛概率 / 平均 RMSE） │ │ ├── sensitivity.ts # 参数敏感性扫描 │ │ ├── comparison.ts # 多场景对比 │ │ └── replay.ts # CSV / JSON 数据回放 │ ├── visual/ │ │ ├── threeView.ts # Three.js 3D 姿态可视化（星空粒子） │ │ ├── orbitView.ts # 3D 轨道视图 │ │ └── charts.ts # ECharts 实时曲线（7 图） │ ├── i18n/ │ │ └── index.ts # 中英文界面切换 │ ├── ui/ │ │ ├── panel.ts # 控制面板 DOM 绑定与参数读写 │ │ ├── stats.ts # 实时统计指标（18 项） │ │ ├── scene.ts # 场景保存 / 加载（JSON v3） │ │ └── alerts.ts # 故障告警系统（新息检测 + 状态灯 + 列表） │ └── css/ │ ├── style.css # 设计令牌与组件基础样式（玻璃拟态） │ ├── main.css # 主控制台布局（三栏 + 图表矩阵） │ └── manual.css # 使用手册页样式 ├── public/ # 静态资源（favicon 等） └── package.json ``` ## 🛠️ 技术栈 | 技术 | 用途 | | ---------------------------------------- | -------------------------------------------- | | [Vite](https://vitejs.dev/) + TypeScript | 工程化与类型安全（多页构建） | | [Three.js](https://threejs.org/) | 三维姿态/轨道可视化（WebGL + OrbitControls） | | [ECharts](https://echarts.apache.org/) | 实时时序曲线与协方差监控 | | [gl-matrix](https://glmatrix.net/) | 四元数运算与矩阵数学 | ## 🎨 设计主题 采用 **Modern Dark（星空白 + 发射蓝）** 航天任务控制中心风格，玻璃拟态面板 + 霓虹辉光 + JetBrains Mono 等宽数字仪表，深色固定主题与 3D 视图背景统一： | 令牌 | 值 | 用途 | | ---- | --------------------- | -------------------------------------- | | 背景 | `#0B0B10` | 页面底色（深空黑） | | 玻璃 | `rgba(20,22,31,0.72)` | 面板玻璃拟态背景（12px 圆角 + 内高光） | | 主色 | `#3B82F6` | 按钮、焦点、分段控制器、辉光 | | 强调 | `#F59E0B` | EKF 曲线、告警、导出按钮 | | 弱化 | `#94A3B8` | 标签、次级文字 | | 等宽 | JetBrains Mono | 遥测数值、统计指标、kbd | ## 📖 使用手册 系统内置完整使用手册（`/manual.html`，顶栏按钮新窗口打开），覆盖快速上手、界面导览、全部参数说明、故障注入模式、高级分析工具、告警系统解读与常见问题。 ## 开源地址 项目地址：https://gitee.com/zd_g/gnc-sim-enhanced 欢迎 Star、Fork、Issue 反馈！ ## ⚠️ 说明 - 本项目为教学/演示用途的姿态确定与控制仿真，阶段1（架构模块化）、阶段2（姿态控制闭环）、阶段3（多传感器融合 + 故障注入 + 告警）、阶段4（轨道动力学 + 蒙特卡洛 + 敏感性 + 回放 + 对比）均已完成 - 太阳敏感器采用简化模型（假设安装在 +Z 轴，主轴 +Z 指向太阳），未建模真实视场遮挡与太阳方向随时间变化 - 磁强计与地磁场为简化偶极子模型，磁场方向随时间绕 Z 轴进动（90 分钟轨道周期），非真实 IGRF - 故障检测基于量测新息模值超阈值（阈值可配置），属简化方案；真实系统常用残差平方加权（CUSUM / χ² 检验） - 图表保留点数由「数据窗口长度」参数控制（默认 1000 点），CSV 导出包含全部历史数据 - 蒙特卡洛 / 敏感性分析为计算密集型任务，期间界面可能短暂卡顿，属正常现象 - 场景文件含版本号（v3）且加载时严格校验，请使用同一平台版本保存与加载 - 建议在 1920×1080 及以上分辨率全屏使用，以获得最佳单屏监控体验（窗口小于 1100px 或高度小于 860px 时自动降级为滚动布局）
Linux 安装 Claude Code 实战：Node.js、npm、GLM 配置一次跑通
# Linux 安装 Claude Code 实战：Node.js、npm、GLM 配置一次跑通  有些工作放在Linux服务器上处理更顺手：看日志、改配置、排查线上问题，或者直接在项目目录里让AI帮忙读代码。 Claude Code和OpenCode都能完成这些事。我个人更习惯Claude Code的终端界面，所以把这次在Linux服务器上的安装过程整理下来。 先说明一下：Claude Code官方目前更推荐原生安装器；本文使用npm，是因为服务器已经有Node.js环境，而且部分网络环境访问官方安装脚本并不稳定。两种方式都能用，按自己的服务器情况选择即可。 ## 整体安装路线  ## 先选安装方式 ### 官方原生安装器 服务器能够正常访问Claude官方地址时，可以直接运行： ~~~bash curl -fsSL https://claude.ai/install.sh | bash ~~~ 原生安装不依赖Node.js，步骤也更短。首次安装Claude Code，优先考虑这种方式。 ### npm全局安装 如果服务器已经装好Node.js，或者官方安装脚本受网络环境影响，也可以使用npm： ~~~bash npm install -g @anthropic-ai/claude-code@latest ~~~ Claude Code官方文档在“高级安装选项 → 使用 npm 安装”中写明：从 `v2.1.198` 开始，npm包需要Node.js 22或更高版本。 不过官方紧接着补充：使用较旧的Node.js时，npm通常只会提示 `EBADENGINE`，安装仍可能完成，`claude` 也可能正常运行，因为npm包最终下载的是不依赖Node.js运行时的原生二进制文件。 所以更准确地说，Node.js 22+是当前npm包声明的安装要求，并不代表Node.js 18下一定无法启动。为了避免安装警告和后续兼容问题，本文仍建议直接使用Node.js 22或更高版本。 官方依据：https://code.claude.com/docs/zh-CN/setup#install-with-npm 本文后面的步骤使用npm方式。 ## 检查Node.js和npm 先执行： ~~~bash node -v npm -v npm config get prefix ~~~  我的环境是： ~~~text Node.js：v24.16.0 npm：11.17.0 ~~~ 这个版本可以直接安装。 如果Node.js低于22，安装时可能出现 `EBADENGINE` 警告。程序未必不能运行，但新装环境没有必要停留在旧版本，建议先通过服务器面板、nvm或系统包管理器切换到Node.js 22或更高版本。 `npm config get prefix` 会告诉你全局包安装到哪里。使用Node项目管理器时，路径可能类似： ~~~text /www/server/nodejs/v24.16.0 ~~~ 使用nvm、系统Node.js或其他面板时，路径会不一样，不需要照抄。 ## 安装Claude Code 执行： ~~~bash npm install -g @anthropic-ai/claude-code@latest ~~~  安装完成后，不要急着配置模型，先确认命令是否正常： ~~~bash claude --version command -v claude ~~~  截图中返回： ~~~text 2.1.218 (Claude Code) /www/server/nodejs/v24.16.0/bin/claude ~~~ 这说明Claude Code已经装好，并且当前Shell能够找到 `claude` 命令。 ## claude命令为什么是一个软链接 npm全局安装命令行工具时，通常会在Node.js的 `bin` 目录创建入口。你输入 `claude`，系统先找到这个入口，再执行真正的程序文件。 可以用下面的命令查看最终位置： ~~~bash readlink -f "$(command -v claude)" ~~~  真实路径会随着Node.js安装方式、版本和Claude Code版本变化。文章中的 `/www/server/nodejs/v24.16.0` 只是这台服务器的结果，不应该写死到脚本中。 想做更完整的安装检查，还可以运行： ~~~bash claude doctor ~~~ ## 官方账号和第三方API，配置方式不同 如果使用Anthropic官方账号，进入项目目录后直接执行 `claude`，按照终端提示登录即可，不需要下面这份GLM配置。 如果使用智谱Coding Plan或兼容Anthropic协议的GLM API，需要修改Claude Code的环境配置。  ## 配置Claude Code接入GLM 先创建配置目录： ~~~bash mkdir -p ~/.claude ~~~ 然后编辑： ~~~bash vim ~/.claude/settings.json ~~~ 写入下面的配置，把 `YOUR_API_KEY` 换成自己的Key： ~~~json { "env": { "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY", "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.7", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]", "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]", "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1, "API_TIMEOUT_MS": "3000000" } } ~~~ 配置完成后，限制文件权限： ~~~bash chmod 600 ~/.claude/settings.json ~~~ 这几个字段可以这样理解： | 配置项 | 作用 | | --- | --- | | `ANTHROPIC_AUTH_TOKEN` | 智谱API Key | | `ANTHROPIC_BASE_URL` | Anthropic兼容接口地址 | | `ANTHROPIC_DEFAULT_HAIKU_MODEL` | Claude Code请求Haiku角色时使用的模型 | | `ANTHROPIC_DEFAULT_SONNET_MODEL` | Claude Code请求Sonnet角色时使用的模型 | | `ANTHROPIC_DEFAULT_OPUS_MODEL` | Claude Code请求Opus角色时使用的模型 | | `API_TIMEOUT_MS` | API请求超时时间 | `glm-5.2[1m]` 中的 `[1m]` 表示该服务商提供的100万Token上下文版本。模型名属于服务商配置，不是Claude Code统一规定的格式。后续智谱调整模型名称时，要以它的官方文档为准。 API Key现在保存在当前Linux用户的配置目录中。不要把 `settings.json` 上传到Git仓库，也不要让其他用户拥有读取权限。 ## 跳过第三方API场景下的首次登录 使用第三方Anthropic兼容接口时，如果启动后仍停留在首次登录流程，可以编辑： ~~~bash vim ~/.claude.json ~~~ 加入： ~~~json { "hasCompletedOnboarding": true } ~~~ 如果 `~/.claude.json` 已经存在，不要整份覆盖，只需要合并 `hasCompletedOnboarding` 字段。 ## 启动Claude Code 先进入准备操作的项目目录： ~~~bash cd /path/to/your/project claude ~~~ 首次进入某个目录时，Claude Code会询问是否信任当前项目。  只有确认代码来源可信时，才选择： ~~~text Yes, I trust this folder ~~~ 因为Claude Code获得授权后，可以读取、修改并执行这个目录里的文件。 进入主界面后，会看到当前模型、项目路径和输入框：  截图中显示 `glm-5.2[1m]`，说明模型映射已经生效。 ## 验证安装是否成功 建议按下面的顺序检查： ~~~bash # 查看版本 claude --version # 检查安装和配置 claude doctor # 查看当前命令入口 command -v claude # 解析软链接 readlink -f "$(command -v claude)" # 发起一次非交互测试，会产生少量模型费用 claude -p "只回复 OK" ~~~ 前四条正常，只能说明程序安装和路径基本没有问题；最后一条能够正常返回，才说明API地址、Key和模型配置也已经打通。 ## 常见问题 ### npm提示EBADENGINE 先看Node.js版本： ~~~bash node -v ~~~ 当前npm安装方式应使用Node.js 22或更高版本。切换版本后重新安装Claude Code。 ### 安装成功，但提示claude命令不存在 检查npm全局目录和当前PATH： ~~~bash npm config get prefix echo "$PATH" ~~~ 临时加入PATH： ~~~bash export PATH="$(npm config get prefix)/bin:$PATH" ~~~ 确认有效后，再把这一行写入 `~/.bashrc` 或 `~/.zshrc`。 ### root用户能运行，普通用户不能运行 不同Linux用户有各自的 `HOME`、npm目录和Claude配置。使用root安装并配置后，普通用户不一定能直接使用。 安装、写入 `~/.claude/settings.json` 和运行 `claude`，最好保持为同一个用户。 ### 返回401或403 重点检查： - `ANTHROPIC_AUTH_TOKEN` 是否正确。 - Key是否拥有对应模型权限。 - `ANTHROPIC_BASE_URL` 是否写错。 - 模型名称是否仍然有效。 ### 请求超时 先确认服务器能否访问API地址： ~~~bash curl -I https://open.bigmodel.cn ~~~ 网络正常后，再检查 `API_TIMEOUT_MS` 和服务商状态。单纯反复重装Claude Code通常解决不了API超时。 ### 界面中的模型和配置不一致 退出当前Claude Code会话，确认 `settings.json` 保存成功后重新启动。仍不一致时，检查是否在另一个Linux用户下运行。 ## 更新和卸载 npm版本建议这样更新： ~~~bash npm install -g @anthropic-ai/claude-code@latest ~~~ 官方文档不建议使用 `npm update -g`，因为它可能受到原始版本范围影响，未必升级到最新版。 卸载命令： ~~~bash npm uninstall -g @anthropic-ai/claude-code ~~~ 如果不再使用原来的第三方API配置，再手动处理 `~/.claude/settings.json` 和 `~/.claude.json`。删除前先确认里面没有其他仍需保留的Claude Code设置。 ## 参考资料 - Claude Code快速开始：https://code.claude.com/docs/zh-CN/quickstart - Claude Code高级设置（npm安装）：https://code.claude.com/docs/zh-CN/setup#install-with-npm - 智谱Claude Code配置：https://docs.bigmodel.cn/cn/coding-plan/tool/claude - Windows下安装Claude Code，使用API Key方式调用GLM：https://xdr630.blog.csdn.net/article/details/158777684 - Claude Code接入国产大模型实战：GLM / Qwen配置全解析：https://xdr630.blog.csdn.net/article/details/160308331 安装本身并不难。真正容易出错的，是Node.js版本、命令路径和第三方API配置被混在一起。按步骤逐项验证，哪一步不通就查哪一步，比反复卸载重装省事得多。 欢迎关注我的公众号【兮动人】，每天分享一些技术文章和实战经验。 
耄耋专属AI Loop全自动编码器技术笔记
> 写给想了解「多AI Agent 在大LOOP时代怎么真上线」的同学 ## 一句话 **Loop Engineering 时代，别只在聊天里写代码——用多 AI Agent，跑一条自己干活的交付 Loop。** 先给这套 Loop 代码编排器定一条简单主线： **需求 Issue → 多角色 AI 协作 → 脚本验证与独立审阅 → 合并 → 固定脚本部署 → 看板盯进度。** 人定目标和验收；AI 负责中间大部分实现与自检；模型不直接登录生产。 --- ## 为什么不只「开个 Cursor 窗口」 聊天式助手擅长帮你改文件，但上线仍要人拉分支、补测、发版、盯结果。Loop 把这些环节收成固定流水线： | | 聊天式 AI 编程 | Loop | |---|---|---| | 起点 | 粘贴上下文 | Issue / 看板目标 | | 过程 | 人来回追问 | 多角色自动推进 | | 质量 | 靠自觉 | 脚本验证 + 独立审阅 | | 上线 | 手工发版 | 确定性发布脚本 | | 可见性 | 对话记录 | 看板阶段与应用入口 | 一句话：**助手帮你写；Loop 帮你把需求送到可点开的版本。** --- ## 技术骨架：三层分工 ```text 触发层 Forgejo Issue（ai-ready） / 看板「新建项目」 编排层 Worker + loopctl + Hermes 五角色 Profile 落地层 verify.sh → PR 合并 → SSH/Compose 发布 → sslip 域名跳转 ``` - **触发层**：习惯还是 Git Issue；新产品也可在看板填「仓库名 + 目标」一键建仓。 - **编排层**：分析 → 架构 → 编码 → 测试 → 审阅；审阅打回最多返工 3 轮；单阶段约 30 分钟超时。 - **落地层**：过门后由脚本部署，看板只监控和跳转，不托管业务前端。 密钥只在服务器 `secrets/`，不进仓库。 --- ## 多 Agent：故意「拆开」，不让一个模型既当运动员又当裁判 | 角色 | 做什么 | 典型产出 | |---|---|---| | 分析 | 收成可验收目标 | `spec.md` | | 架构 | 拆任务、定边界 | `plan.md` | | 编码 | 改业务代码与测试 | 仓库 diff | | 测试 | 独立补测、跑验证 | 测试报告 | | 审阅 | 只评不改，给通过/打回 | `review.json` | 执行侧用 Hermes 多 Profile，工具集刻意收窄（文件 / 终端 / 必要时代码执行），并设轮次上限，避免一轮对话无限烧 Token。 模型也可分层：编码侧重代码模型，测试用更快模型，审阅用更稳的模型——**质量门与写代码的人不是同一个「脑」**。 ## 配置落在哪 ### 编排层（仓库） `config/loop.json` 只规定： - 五角色各自用哪个 Profile 名 - 工具集（分析 / 架构 / 审阅：`file,terminal`；编码 / 测试再加 `code_execution`） - 单阶段轮次上限、YOLO、返工次数、超时 其中 `hermes.models` 可以按角色覆盖模型名；**留空则用 Profile 默认值**。 ### 执行层（服务器 Hermes） 真正的模型 ID、`base_url`、API Key 写在各 Profile 的 `config.yaml`（例如 `/root/.hermes/profiles/loop-coder/config.yaml`）。 线上现行大致是： | 角色 | 模型 | |---|---| | 分析 / 架构 / 编码 | `ark-code-latest`（火山方舟选GLM5.2） | | 测试 | `deepseek-v4-flash` | | 审阅 | `deepseek-v4-pro` |  ### 小技巧 如果想真正的分饰多角，完全可以多买几个便宜的Agent Plan分别挂不同对应角色能力的**LLM**，但这里由于成本控制的原因，最少两个**LLM**对应不同能力就可以完成基本工作了。 ### 人格层（SOUL） 仓库 `roles/*.md` 同步进各 Profile 的 `SOUL.md`，约束「只做什么、不做什么」： - **模型**负责能力 - **SOUL**负责边界 ### 调用链 ```text Issue Worker → loopctl → 对应 Profile 的 Hermes（--oneshot，瘦工具集）→ 该 Profile 配置的模型 ``` --- ## 有边界的自治（比「全自动」更重要） **会自动做：** 读仓、改码、跑校验、开/合 PR、按脚本部署。 **不会自动做：** 没目标乱开需求、跳过质量门上生产、把密钥写进 Git。 **人能介入：** 看板看卡点、一键重跑；紧急可停 Worker。 发布永远走 `release.sh` / SSH 一类确定性路径，而不是让 Agent 临时拼命令登生产。 --- ## 看板：把黑盒变成进度条 看板回答三件事： 1. 现在跑到哪（分析 / 架构 / 编码 / 测试 / 审阅 / 发布） 2. 有没有被打回、卡在哪 3. 应用在哪打开（当前交付 + 历史项目各自地址） 多项目时：**一仓一应用、独立端口、独立 `*.sslip.io` 域名**。改哪个程序，Issue 就开在哪个仓库。   --- ## 一次真实路径长什么样 1. 看板新建，或在目标仓开 Issue 并打 `ai-ready` 2. Worker 领取 → 工作区拉出 `ai/issue-N` 分支 3. 五角色流水线跑完，产物落在 `.loop/current/` 4. 质量门通过 → PR 合并 5. `deploy_once` 部署 Staging/Production，写好跳转域名 6. 打开 `{项目名}.xxx.sslip.io` 验收 试点里我们用这条链路交付过多智能体对话应用、内容创作平台等——从「一句话目标」到「浏览器能点开」，中间大部分由流水线完成。  --- ## 适合什么，不适合什么 **适合：** 中小功能、脚手架增量、内部试点、需求边界写得清的迭代。 **暂不适合：** 无人值守改核心账务、无评审的大重构、强合规唯一发布通道。 产出质量仍然取决于：需求是否写清、模板是否匹配、模型额度与提示词。 ## 目前Loop编排器自动完成的项目展示    --- ## 结语 Loop 的技术选择可以概括成三句： 1. **角色分离**，降低「自写自审」幻觉； 2. **脚本守门**，模型负责想和改，脚本负责过不过、能不能上； 3. **看板可见**，自动跑也不变成黑盒。 它不是取代工程师，而是把重复的「领任务 → 改代码 → 验证 → 发版」收成一条可观测流水线，让人把时间花在目标与验收上。
新手SpringSecurity6.0源码流程总结
自己看的源码理解总结的，后端代码抄别人的能运行听不赖。 认证：  鉴权： 
我的AI编程工作流：从需求判断到上线复盘，搭一套 AI 项目自动化流水线
我的AI编程工作流不是让 AI 帮我写一段代码，而是让它围绕需求、原型、方案、任务、开发、测试、部署、日志和复盘持续运转。 ```text 需求判断 → 原型设计 → 技术方案 → 任务拆解 → 前后端开发 → 测试联调 → 代码审查 → 部署上线 → 日志排查 → 复盘沉淀 ``` 这不是一个“问一句答一句”的 AI 聊天窗口，而是一个后台开发助理。  它应该能： ```text 每天自动检查项目 发现问题进入 inbox 没有问题自动归档 低风险问题生成修复建议 中高风险问题等待人工确认 PR 自动做风险审查 部署前自动生成检查清单 上线后自动看日志 每周自动生成复盘和技术债 ``` 这篇文章就完整拆一件事： **如何把 AI 编程能力放进一个有边界、有触发、有产物、有审批、有复盘的软件工程流水线里。** 这不是“全自动开发”。 我的核心判断是： **AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。** **AI 不应该直接接管项目，而应该进入有触发、有产物、有审批的流水线。** **能自动化的是巡检、整理、初稿、检查和低风险修复；不能自动化的是方向判断、风险审批和上线责任。** **真正有价值的 AI 工作流，不是让 AI 多写一点代码，而是让项目过程变得可追踪、可审查、可复盘。** --- ## 一、先说清楚：这不是普通 AI 工具流 这套系统叫： ### AI 项目交付流水线 它不是一个软件，也不是一个插件，而是一套项目组织方式。 ```text 项目自己有一套流水线 每个阶段有固定输入 每个阶段有固定产物 每个阶段有触发器 每个阶段有 Skill 每个阶段有风险等级 每个阶段有人工 Gate 每个阶段结束后能沉淀到下一轮 ``` 底层用： ```text Codex Automations Codex / Claude Code Agent Skills AGENTS.md MCP GitHub Actions GitHub PR Review 本地脚本 人工审批 ``` Skill 可以把指令、资源和可选脚本打包成任务专用能力，让 Codex 更稳定地执行某类工作流。 编码Agent 会在开始工作前读取项目里的 `AGENTS.md`，把这些指令作为项目上下文和行为规范。 MCP 定义为连接 AI 应用和外部系统的开放标准，可以让 AI 应用连接本地文件、数据库、搜索引擎、工具和工作流。 同时，MCP Tools 规范也明确建议为了安全和信任，应保留 human-in-the-loop，让用户能够拒绝工具调用，并清楚看到哪些工具暴露给模型。 这套系统的底层原则是： ```text 能只读，就先只读。 能生成报告，就先生成报告。 能进入 inbox，就不要直接改生产。 能人工确认，就不要自动上线。 ``` --- ## 二、总架构：AI 项目交付流水线的 6 层 先看整体架构。  每一层负责的事情不一样。 | 层级 | 作用 | 例子 | | ----- | --------------- | ------------------------ | | 产物层 | 所有阶段必须留下可追踪产物 | PRD、AC、任务卡、测试报告、日志报告 | | 触发层 | 决定什么时候让 AI 介入 | 每日巡检、PR 触发、手动触发 | | 能力层 | 给 AI 方法、规则和外部能力 | Skills、MCP、AGENTS.md | | 执行层 | 生成、检查、修复、汇报 | Codex、Claude Code、Cursor | | 审批门层 | 控制风险，防止 AI 越权 | 人工审批、风险分级 | | 复盘反馈层 | 把每次执行沉淀成经验 | 周报、复盘、更新 Skill | 普通 AI 编程工具流只停留在 Execution Layer。 这套流水线的重点是：**每一次 AI 介入都必须有输入、有输出、有边界、有审批、有复盘。** --- ## 三、Codex常用功能 #### 1.插件安装  在Codex左上角插件处即可下载以上所有所需的MCP包括computer use，FIgma，Playwright，Github MCP等。 #### 2.自动化工作流安排  在codex的左上角即可进行以上所有工作流的编排，可以自行选择执行时间、重复次数、模型调用和项目所在的工作数分支还是本地执行等。也可以直接将本文放进对话框中后续再进行根据自己的实际情况微调直接执行实现AI编程的工作流。 #### 3.Plan模式 需求分析和分阶段任务的阶段建议使用Plan Mode模式，会给出项目的阶段方案和测试方案等，参考如下：  #### 4.Goal模式 如果你有了具体的Plan想让Codex长时间往一个目标执行任务，你就可以使用Goal模式，他会长时间进行工作直到达到你的目标，参考图如下：  #### 5.关于本文的前端原型图设计 具体可以使用文章提到过的product design和fronted design 以及结合Figma设计前端原型图，参考图如下：  ## 四、先定义三类触发器 成熟的 AI 流水线不是要所有事情都自动化应该有三类触发器 |触发器|适合什么|例子| |---|---|---| |定时触发|巡检、报告、提醒、复盘|每天 9 点测试巡检，每周日复盘| |事件触发|PR、push、issue、CI 失败|PR 自动审查，构建失败分析| |手动触发|高判断、高风险、高成本任务|需求确认、技术方案、生产部署| 这对应到 AI 项目流水线里，就是： ```text 定时触发：让 AI 定期巡检 事件触发：让 AI 响应项目变化 手动触发：让 AI 处理高价值但需要人确认的节点 ``` 一句话： **自动化不是让 AI 自己做决定，而是让 AI 在合适的时间自动收集证据、生成初稿、发现风险，然后把需要人判断的东西推到我面前。** --- ## 五、再定义五个风险等级 没有风险等级，AI 自动化迟早会失控。 我把任务分成五级： |等级|含义|AI 可以做什么|是否需要人工确认| |---|---|---|---| |L0|只读分析|读文档、读日志、读 diff、生成报告|不需要| |L1|低风险产物|生成 PRD 初稿、任务卡、README、复盘|需要审核后进入下一阶段| |L2|低风险修改|改文档、补测试、修文案、轻量 UI|合并前确认| |L3|中高风险修改|改接口、改权限、改数据库、重构模块|修改前和合并前都确认| |L4|生产高风险|部署生产、删除数据、改密钥、迁移库|AI 禁止自动执行| 这个表是整套流水线的安全底座。 每张任务卡都要写： ``` 风险等级：L0 / L1 / L2 / L3 / L4 自动化等级：只读 / 仅生成草稿 / AI 可修改 / AI 可修改但必须审查 / 仅人工处理 ``` 比如： ```text README 更新：L1，draft_only 补单元测试：L2，ai_can_patch_with_review 新增登录接口：L3，ai_can_patch_with_review 修改生产 Nginx：L4，manual_only 数据库迁移：L4，manual_only ``` 这就体现了第一条核心原则： **AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。** --- ## 六、第一步：搭项目目录 先在项目根目录建这套结构。 ```text project-root/ ├── AGENTS.md ├── .agents/ │ └── skills/ │ ├── 01-idea-review/ │ │ └── SKILL.md │ ├── 02-product-design/ │ │ └── SKILL.md │ ├── 03-tech-spec/ │ │ └── SKILL.md │ ├── 04-task-breakdown/ │ │ └── SKILL.md │ ├── 05-implementation/ │ │ └── SKILL.md │ ├── 06-test-triage/ │ │ └── SKILL.md │ ├── 07-review-gate/ │ │ └── SKILL.md │ ├── 08-deploy-readiness/ │ │ └── SKILL.md │ ├── 09-log-triage/ │ │ └── SKILL.md │ └── 10-postmortem/ │ └── SKILL.md ├── .github/ │ ├── workflows/ │ │ ├── ci.yml │ │ ├── codex-pr-review.yml │ │ └── release-check.yml │ └── codex/ │ └── prompts/ │ ├── pr-review.md │ ├── release-check.md │ ├── deploy-check.md │ └── weekly-review.md ├── ideas/ ├── docs/ ├── prototype/ ├── tasks/ ├── inbox/ ├── reports/ └── deploy/ ``` 这套目录是我为了让 AI 工作流可沉淀、可追踪、可复盘设计的项目结构。 核心目的只有一个： ```text 不要让 AI 产物散落在聊天记录里。 所有东西必须落到文件系统。 ``` 需求审查进 `docs/idea-review/`。 任务卡进 `tasks/`。 自动巡检结果进 `inbox/`。 部署检查进 `deploy/`。 复盘进 `reports/`。 这就是 Artifact Layer。 --- ## 七、第二步：写 AGENTS.md，先给 AI 立规矩 没有 `AGENTS.md`，AI 每次进项目都在猜。 先把项目技术栈、命令、风险边界、审批规则先写清楚。 ```` # AGENTS.md ## 项目角色 你是这个项目的后台开发助理。 你可以协助完成： - 想法审查 - 产品原型 - 技术方案 - 任务拆解 - 低风险实现 - 测试联调 - 代码审查 - 部署前检查 - 日志排查 - 每周复盘 在没有人工批准之前，你不能做高风险决策。 ## 项目技术栈 后端： - Java 17 - Spring Boot 3 - MyBatis-Plus - MySQL - Redis 前端： - Vue 3 - TypeScript - Vite - Element Plus 部署： - Docker Compose - Nginx - HTTPS - Cloudflare 或反向代理 ## 常用命令 后端： bash mvn test mvn spring-boot:run 前端： cd frontend npm install npm run build npm run dev Docker： docker compose up -d --build docker compose ps docker compose logs -f backend ## 工作流规则 修改代码前： 1. 先阅读相关文档和文件。 2. 说明你的执行计划。 3. 列出你打算修改的文件。 4. 判断风险等级。 5. 如果任务属于中风险或高风险，必须等待人工确认。 修改代码后： 1. 总结修改了哪些文件。 2. 运行必要的测试。 3. 报告测试结果。 4. 说明剩余风险。 5. 未经过验证，不能声称任务完成。 ## 风险等级 L0：只读分析 - 读取文档 - 读取日志 - 读取 diff - 生成报告 L1：仅生成草稿 - 生成 PRD 初稿 - 生成任务卡 - 生成 README 初稿 - 生成周报 L2：低风险修改 - 文档更新 - 测试补充 - UI 文案调整 - 非生产脚本的小改动 L3：中高风险修改 - 新增 API 接口 - 认证相关逻辑 - 权限相关逻辑 - 数据库访问逻辑 - 业务模块重构 L4：生产高风险 - 生产部署 - 密钥 - 数据库迁移 - Nginx / Docker / CI 变更 - 支付 / 积分 / 扣费逻辑 - 安全策略变更 ## 硬性规则 - 不能提交密钥、API Key、密码、Token 或 `.env` 文件。 - 不能删除测试，除非得到明确批准。 - 不能削弱认证或权限控制。 - 不能擅自修改已经应用过的历史迁移文件。 - 不能把数据库、Redis、Docker API 或内部服务暴露到公网。 - 不能自动部署到生产环境。 - 不能修改生产数据。 - 如果不确定，必须先请求确认。 ## 代码审查关注点 审查变更时，重点关注： - 是否缺少测试 - 是否引入安全回退 - 是否绕过权限 - 是否记录了用户敏感信息 - 是否泄露密钥 - 是否出现 N+1 查询 - 是否存在数据库迁移风险 - 是否存在部署风险 - 是否修改了无关文件 ```` 这份文件是整个流水线的“施工规范”。 Codex、Claude Code 会读取 `AGENTS.md` 作为项目级指导，把里面的技术栈、命令、风险边界和 Review 规则带入后续任务。 --- ## 八、第三步：写 10 个 Skill Skill 的价值是把同类任务的经验固化下来。 注意：这里的路径不要写成 `skills/xxx/SKILL.md`。 Codex 仓库级 Skill 默认应该放在： ```text .agents/skills/{skill-name}/SKILL.md ``` ### 1. idea-review-skill(需求分析skill) 路径： ```text .agents/skills/01-idea-review/SKILL.md ``` 内容： ```md --- name: idea-review-skill description: 在实现项目之前审查想法。用于判断真实痛点、目标用户、MVP 范围、风险和简历价值。 --- # 想法审查 Skill ## 目标 帮助判断一个想法是否值得进入开发流水线。 ## 输入 - 项目想法描述 - 目标用户 - 开发者背景 - 可投入时间 - 已有替代品，如果有的话 ## 输出 生成一份想法审查报告，包含： 1. 判断结果：执行 / 等待 / 放弃 2. 真实痛点 3. 目标用户 4. 现有替代品 5. MVP 范围 6. 7 天可行性 7. 技术风险 8. 产品风险 9. 简历价值 10. 前 7 天计划 ## 规则 - 不能自动创建开发任务。 - 不能修改源代码。 - 如果缺少证据，标记为“需要调研”。 - 审查要严格。如果想法模糊，优先给出“等待”或“放弃”。 ``` ### 2. product-design-skill（前端原型设计图skill） 路径： ```text .agents/skills/02-product-design/SKILL.md ``` 内容： ```md --- name: product-design-skill description: 在前端编码之前，设计产品流程、页面结构、用户状态和交互逻辑。 --- # 产品设计 Skill ## 目标 不要直接生成前端代码。 先设计产品流程、信息结构和页面状态。 ## 输出 1. 用户目标 2. 核心用户流程 3. 页面列表 4. 页面信息结构 5. 核心组件 6. 加载 / 空状态 / 错误 / 成功状态 7. 表单校验规则 8. 危险操作和二次确认 9. 桌面端 / 移动端图片预览 10. 交给前端实现的说明 ## 规则 - 不要编造业务逻辑。 - 不清楚的需求标记为“待确认”。 - 每个页面都必须包含加载、空状态、错误和成功状态。 - 优先使用简单流程，不要一开始设计复杂页面。 ``` ### 3. tech-spec-skill（技术选型和后端架构skill) 路径： ```text .agents/skills/03-tech-spec/SKILL.md ``` 内容： ```md --- name: tech-spec-skill description: 把已确认的 PRD 和原型转换成技术方案、接口设计、数据库草案、风险清单和任务边界。 --- # 技术方案 Skill ## 目标 在正式实现之前生成技术方案。 ## 输出 1. 模块设计 2. 后端包结构 3. 前端页面和组件结构 4. API 接口 5. 请求和响应结构 6. 数据库表和索引 7. 认证和权限边界 8. 错误处理 9. 日志和 traceId 10. 缓存策略 11. 限流策略 12. 测试策略 13. 部署影响 14. 风险清单 ## 规则 - 不能修改源代码。 - 不能创建数据库迁移文件。 - 不确定的决策标记为“需要人工确认”。 ``` ### 4. task-breakdown-skill(分阶段实现任务skill) 路径： ```text .agents/skills/04-task-breakdown/SKILL.md ``` 内容： ```md --- name: task-breakdown-skill description: 把已确认的技术方案拆成可执行任务卡，包含范围、风险等级、自动化等级和验证命令。 --- # 任务拆解 Skill ## 目标 创建 AI 编码 Agent 可以安全执行的任务卡。 ## 每张任务卡必须包含 1. 任务目标 2. 任务范围 3. 允许修改的文件 4. 禁止修改的文件 5. 验收标准 6. 验证命令 7. 风险等级 8. 自动化等级 9. 人工 Gate ## 自动化等级 - 仅人工处理 - AI 辅助分析 - AI 可以修改 - AI 可以修改但必须审查 ## 规则 - 不能修改源代码。 - 每个任务必须足够小，方便审查。 - 高风险文件必须标记为“仅人工处理”或“AI 辅助分析”。 ``` ### 5. implementation-skill（每阶段开发、测试及验收skill) 路径： ```text .agents/skills/05-implementation/SKILL.md ``` 内容： ```md --- name: implementation-skill description: 按已批准任务卡小步执行开发，并输出测试结果和变更摘要。 --- # 开发实现 Skill ## 目标 只实现 `tasks/ready/` 中已经批准的任务。 ## 工作流程 1. 读取 AGENTS.md。 2. 读取任务卡。 3. 读取相关文件。 4. 提出执行计划。 5. 判断风险等级。 6. 如有需要，等待人工确认。 7. 只修改允许修改的文件。 8. 运行验证命令。 9. 总结变更和风险。 ## 规则 - 不能从 backlog 中自行挑任务。 - 不能修改禁止修改的文件。 - 验证没有通过，不能把任务标记为完成。 - 不能自动修改生产配置。 ``` ### 6. test-triage-skill(测试和修复skill) 路径： ```text .agents/skills/06-test-triage/SKILL.md ``` 内容： ```md --- name: test-triage-skill description: 运行或分析项目验证检查，并生成测试排查报告。 --- # 测试排查 Skill ## 目标 发现构建失败、测试失败和有风险的 TODO/FIXME 变更。 ## 检查项 1. 后端测试 2. 前端构建 3. Docker Compose 配置 4. 健康检查接口，如果有的话 5. TODO/FIXME 扫描 6. 最近变更文件是否缺少测试 ## 输出 - 状态：自动归档 / 需要查看 / 阻塞发布 / 需要人工处理 - 证据 - 疑似原因 - 最小下一步 - 建议负责人 ## 规则 - 除非明确批准，否则不能修改源代码。 - 如果全部通过，标记为“自动归档”。 ``` ### 7. review-gate-skill（代码合并前审查skill) 路径： ```text .agents/skills/07-review-gate/SKILL.md ``` 内容： ```md --- name: review-gate-skill description: 审查 diff 和 PR，关注安全、正确性、测试、部署和无关改动。 --- # 代码审查门禁 Skill ## 目标 在合并前审查变更。 ## 重点关注 1. 安全回退 2. 认证 / 权限绕过 3. 密钥泄露 4. 用户敏感信息日志 5. 删除或削弱测试 6. 数据库迁移风险 7. 部署配置风险 8. 意外的无关改动 9. N+1 查询 10. 缺少错误处理 ## 审查结论 - 可以合并 - 需要继续审查 - 禁止合并 ## 规则 - 除非明确要求，否则不要重写代码。 - 优先关注 P0 / P1 高风险问题。 - 如果涉及部署、认证、数据库、密钥或 CI 变更，至少标记为“需要继续审查”。 ``` ### 8. deploy-readiness-skill(上线前部署skill) 路径： ```text .agents/skills/08-deploy-readiness/SKILL.md ``` 内容： ```md --- name: deploy-readiness-skill description: 检查部署准备情况、回滚计划、冒烟测试、端口、密钥、日志和生产风险。 --- # 部署准备检查 Skill ## 目标 准备部署检查清单和回滚计划。不能自动部署。 ## 检查项 1. CI 结果 2. docker-compose.yml 3. Nginx 配置 4. .env.example 5. 暴露端口 6. 数据库迁移 7. 数据卷挂载 8. 日志 9. 备份策略 10. 回滚命令 11. 冒烟测试 12. 安全风险 ## 输出 - deploy-readiness.md - rollback-plan.md - smoke-test.md ## 规则 - 不能部署到生产环境。 - 不能打印密钥。 - 有风险的内容必须标记为“需要人工处理”。 ``` ### 9. log-triage-skill（日志排查skill) 路径： ```text .agents/skills/09-log-triage/SKILL.md ``` 内容： ```md --- name: log-triage-skill description: 在部署后或定时任务中分析日志和健康信号。 --- # 日志排查 Skill ## 目标 从日志和健康检查中发现运行问题。 ## 检查项 1. 5xx 错误 2. Nginx 404 / 502 异常增长 3. 认证失败 4. AI 模型超时 5. JSON 解析失败 6. 限流错误 7. PDF 导出失败 8. 容器重启 9. 磁盘 / 内存告警 ## 输出 - 严重程度：信息 / 警告 / 错误 / 严重 - 证据 - 疑似原因 - 建议下一步 - 是否需要人工处理 ## 规则 - 默认只读。 - 不能删除日志。 - 不能修改生产配置。 ``` ### 10. postmortem-skill(复盘和沉淀skill) 路径： ```text .agents/skills/10-postmortem/SKILL.md ``` 内容： ```md --- name: postmortem-skill description: 生成周报、发布复盘、技术债、简历表达和面试问题。 --- # 复盘沉淀 Skill ## 目标 把项目活动转化成可复用经验和下一步行动。 ## 输入 - tasks/done - inbox/test - inbox/review - inbox/deploy - inbox/logs - 已合并 PR - 本周提交记录 ## 输出 1. 本周交付了什么 2. 哪些地方失败了 3. 剩余风险 4. 技术债 5. 下周计划 6. AGENTS.md 更新建议 7. Skill 更新建议 8. 简历表达候选 9. 面试问题 10. 博客选题 ## 规则 - 不能修改源代码。 - 区分事实和建议。 - 不确定的结论标记为“需要复查”。 ``` 这 10 个 Skill 就是能力层。 --- ## 九、第四步：写 10 个流水线节点 下面开始搭真正的流水线。 每个节点都要包含： ```text 触发方式 输入 Skill AI 动作 输出 人工 Gate ``` --- ## 节点 1：需求判断 Pipeline 目标：不让自己冲动开项目。 触发方式： ```text 手动触发：新建 ideas/xxx.md 定时触发：每周扫描 ideas/ ``` 输入： ```text ideas/*.md ``` 输出： ```text docs/idea-review/{idea-name}.md ``` 自动化 Prompt： ```text 使用 idea-review-skill。 扫描 ideas/ 目录。 对于每一个还没有在 docs/idea-review/ 里生成审查报告的想法，创建一份想法审查报告。 不能自动创建开发任务。 不能修改源代码。 每个想法都要输出： - 执行 / 等待 / 放弃 - 真实痛点 - 目标用户 - 现有替代品 - MVP 范围 - 7 天可行性 - 简历价值 - 技术风险 - 产品风险 如果没有新的想法，把本次运行标记为“自动归档”。 ``` 人工 Gate： ```text 只有我把判断结果改成“执行”，才允许进入 PRD 阶段。 ``` 核心判断： ```text AI 是立项审计员，不是产品老板。 ``` --- ## 节点 2：原型设计 Pipeline 目标：先把产品流程想清楚，不让 AI 直接写前端。 触发方式： ```text 手动触发 ``` 输入： ```text docs/PRD.md docs/AC.md ``` 输出： ```text prototype/page-flow.md prototype/DESIGN.md prototype/wireframe.html ``` 自动化 Prompt： ```text 使用 product-design-skill。 读取 docs/PRD.md 和 docs/AC.md。 生成： - prototype/page-flow.md - prototype/information-architecture.md - prototype/states.md - prototype/DESIGN.md - prototype/wireframe.html 不能修改前端源代码。 如果可以使用 browser MCP： - 打开 prototype/wireframe.html。 - 检查主流程是否清晰可见。 - 检查加载、空状态、错误、成功状态是否完整。 - 报告页面布局问题。 最后输出检查清单： - 核心流程是否清晰？ - 所有状态是否覆盖？ - 哪些部分需要人工确认？ ``` 人工 Gate： ```text 我确认原型后，才能进入技术方案阶段。 ``` 核心判断： ```text 前端自动化不是先写 Vue，而是先生成产品结构和页面状态。 ``` --- ## 节点 3：技术方案 Pipeline 目标：把产品需求转成可开发的技术合同。 触发方式： ```text 手动触发 ``` 输入： ```text docs/PRD.md docs/AC.md prototype/DESIGN.md 当前代码结构 ``` 输出： ```text docs/tech-spec.md docs/api-spec.md docs/db-schema-draft.sql docs/risk-checklist.md ``` 自动化 Prompt： ```text 使用 tech-spec-skill。 读取： - docs/PRD.md - docs/AC.md - prototype/DESIGN.md - 当前项目代码结构 生成： - docs/tech-spec.md - docs/api-spec.md - docs/db-schema-draft.sql - docs/risk-checklist.md 技术方案必须包含： 1. 模块设计 2. 后端包结构 3. 前端页面和组件结构 4. API 接口 5. 请求和响应结构 6. 数据库表和索引 7. 认证和权限边界 8. 错误处理 9. 日志和 traceId 10. 缓存策略 11. 限流策略 12. 测试策略 13. 部署影响 14. 风险清单 不能修改源代码。 不能创建数据库迁移文件。 所有不确定的决策都标记为“需要人工确认”。 ``` 人工 Gate： ```text 未审批 tech-spec.md，不允许拆任务。 ``` 核心判断： ```text 技术方案是 AI 开发前的边界合同。没有合同就开工，本质是让 AI 猜架构。 ``` --- ## 节点 4：任务拆解 Pipeline 目标：把技术方案拆成任务卡，并给每个任务标注风险等级。 触发方式： ```text 手动触发 docs/tech-spec.md 变更后触发 ``` 输入： ```text docs/tech-spec.md docs/api-spec.md docs/risk-checklist.md ``` 输出： ```text tasks/backlog/*.md ``` 任务卡模板： ````md # 任务：001-login-api ## 目标 实现用户登录接口。 ## 范围 允许修改的文件： - backend/src/main/java/.../AuthController.java - backend/src/main/java/.../AuthService.java - backend/src/main/java/.../dto/LoginRequest.java - backend/src/main/java/.../vo/LoginResponse.java 禁止修改的文件： - docker-compose.yml - nginx.conf - 生产环境 .env - 已经应用过的历史迁移文件 ## 验收标准 - 正确账号密码返回 accessToken - 错误密码返回统一错误码 - 空字段返回参数校验错误 - 密码不明文存储 - 测试通过 ## 验证命令 ```bash mvn test ``` ## 风险等级 L3：中高风险修改 ## 自动化等级 AI 可以修改，但必须审查。 ## 人工 Gate 需要人工看 diff 后合并。 ```` 自动化 Prompt： ```text 使用 task-breakdown-skill。 读取 docs/tech-spec.md、docs/api-spec.md、docs/risk-checklist.md。 在 tasks/backlog/ 下创建任务卡。 每张任务卡都必须包含： - 任务目标 - 任务范围 - 允许修改的文件 - 禁止修改的文件 - 验收标准 - 验证命令 - 风险等级 - 自动化等级 - 人工 Gate 不能修改源代码。 ``` 人工 Gate： ```text 只有我把任务从 tasks/backlog 移到 tasks/ready，Codex 才能执行。 ``` 核心判断： ```text AI 不是自动抢任务，而是领取已批准的任务卡。 ``` --- ## 节点 5：前后端开发 Pipeline 目标：让 AI 小步执行，不接管整个项目。 触发方式： ```text 任务被人工移动到 tasks/ready GitHub issue 加 codex-ready 标签 ``` 输入： ```text tasks/ready/*.md AGENTS.md 相关源码 ``` 输出： ```text branch / worktree diff test result tasks/done/{task}.md ``` 自动化 Prompt： ```text 先读取 AGENTS.md。 从 tasks/ready/ 中选择一个任务。 不要立刻开始写代码。 先输出： 1. 任务摘要 2. 需要读取的文件 3. 计划修改的文件 4. 风险等级 5. 验证命令 6. 是否需要人工确认 如果任务风险等级是 L3 或 L4，必须停止并等待确认。 如果已经批准： - 创建或使用独立 branch / worktree。 - 只修改任务卡允许修改的文件。 - 运行验证命令。 - 写出变更摘要。 - 只有测试通过，才能把任务移动到 tasks/done。 ``` 人工 Gate： ```text 所有代码进入 main 前必须 PR。 L3 任务修改前必须确认。 L4 任务 AI 不允许自动执行。 ``` 核心判断： ```text AI 可以执行任务，但不能突破任务卡边界。 ``` --- ## 节点 6：测试联调 Pipeline 目标：让失败不再沉默。 触发方式： ```text 每日定时 PR 更新 手动触发 ``` 输入： ```text 源码 测试命令 构建命令 健康检查接口 ``` 输出： ```text inbox/test/test-report-{date}.md ``` 自动化 Prompt： ```text 使用 test-triage-skill。 运行项目验证检查清单： 1. 后端测试 2. 前端构建 3. Docker Compose 配置验证 4. 如果有健康检查接口，就检查健康接口 5. 扫描 TODO / FIXME 变更 把报告写入 inbox/test/test-report-{today}.md。 如果所有检查都通过： - 标记为“自动归档”。 如果任意检查失败： - 标记为“需要人工查看”。 - 解释失败原因。 - 给出最小修复建议。 - 除非明确批准，否则不能修改代码。 ``` 处理规则： ```text 全部通过：自动归档 低风险失败：需要人工查看 影响部署：阻塞发布 涉及安全/数据库：需要人工处理 ``` 核心判断： ```text 测试联调的自动化价值，不是让 AI 修所有 Bug，而是让失败不再沉默。 ``` --- ## 节点 7：代码审查 Pipeline 目标：AI 写的代码必须过 Review Gate。 触发方式： ```text pull_request opened pull_request synchronize @codex review ``` 输入： ```text PR diff AGENTS.md review guidelines ``` 输出： ```text PR review comment inbox/review/pr-{number}.md ``` Codex GitHub integration 支持在 PR 评论中使用 `@codex review` 请求审查，也可以开启 automatic reviews。Codex 会读取仓库里的 `AGENTS.md` review guidance，并优先标出 P0/P1 高优先级风险。 PR Review Prompt： ```md # .github/codex/prompts/pr-review.md 你正在审查一个 Pull Request。 请先读取 AGENTS.md，并遵守其中的代码审查规范。 重点关注： 1. 是否引入安全回退 2. 是否绕过认证或权限 3. 是否泄露密钥 4. 是否记录用户敏感信息 5. 是否删除或削弱测试 6. 是否存在数据库迁移风险 7. 是否存在部署配置风险 8. 是否出现意外的无关改动 9. 是否引入 N+1 查询 10. 是否缺少错误处理 输出： - 结论：可以合并 / 需要继续审查 / 禁止合并 - P0 问题 - P1 问题 - P2 问题 - 必须修复项 - 需要人工确认的问题 除非明确要求，否则不要重写代码。 ``` GitHub Action 示例： ```yaml name: Codex PR Review on: pull_request: types: [opened, synchronize, reopened] jobs: codex-review: runs-on: ubuntu-latest permissions: contents: read pull-requests: write steps: - uses: actions/checkout@v5 with: ref: refs/pull/${{ github.event.pull_request.number }}/merge fetch-depth: 0 persist-credentials: false - name: Run Codex Review uses: openai/codex-action@v1 with: openai-api-key: ${{ secrets.OPENAI_API_KEY }} prompt-file: .github/codex/prompts/pr-review.md output-file: codex-output.md ``` GitHub Actions workflow 可以通过 `pull_request` 等事件触发，适合把审查、测试、构建等流程接进 PR 生命周期。 人工 Gate： ```text 禁止合并：不能合并 需要继续审查：必须处理 可以合并：仍需人工最终确认 ``` 核心判断： ```text 代码审查不是整套系统的全部，它只是 AI 项目流水线里的风险门禁。 ``` --- ## 节点 8：部署上线 Pipeline 目标：AI 做 readiness，人做 deploy。 触发方式： ```text release 分支 tag 创建前 手动触发 ``` 输入： ```text CI 结果 docker-compose.yml nginx.conf .env.example migration ``` 输出： ```text deploy/deploy-readiness.md deploy/rollback-plan.md deploy/smoke-test.md ``` 自动化 Prompt： ```text 使用 deployment-readiness-skill。 检查这个项目是否具备部署条件。 检查： 1. CI 结果 2. docker-compose.yml 3. Nginx 配置 4. .env.example 5. 暴露端口 6. 数据库迁移 7. 数据卷挂载 8. 日志 9. 备份策略 10. 回滚命令 11. 冒烟测试 12. 安全风险 生成： - deploy/deploy-readiness.md - deploy/rollback-plan.md - deploy/smoke-test.md 不能自动部署。 所有有风险的项目都必须标记为“需要人工处理”。 ``` 部署前清单： ```text [ ] 后端构建通过 [ ] 前端构建通过 [ ] Docker Compose 配置通过 [ ] 数据库迁移可回滚或已备份 [ ] Nginx 配置通过 nginx -t [ ] 80/443 暴露合理 [ ] MySQL / Redis 不暴露公网 [ ] .env.example 字段完整 [ ] 生产密钥未进入 Git [ ] 备份可用 [ ] rollback-plan.md 已生成 [ ] smoke-test.md 已生成 ``` 人工 Gate： ```text 生产部署必须人工执行。 AI 只能生成检查清单和命令。 ``` 核心判断： ```text AI 可以帮我准备上线，但不能替我承担生产事故。 ``` --- ## 节点 9：日志排查 Pipeline 目标：上线后让 AI 值班。 触发方式： ```text 每天 9 点 部署后 30 分钟 出现错误激增时 ``` 输入： ```text 后端日志 Nginx 日志 AI 调用日志 Docker 日志 健康检查接口 ``` 输出： ```text inbox/logs/log-triage-{date}.md ``` 自动化 Prompt： ```text 使用 log-triage-skill。 分析最近 24 小时日志。 检查： - 5xx 错误 - Nginx 404 / 502 异常增长 - 认证失败 - AI 调用失败 - 模型超时 - JSON 解析失败 - PDF 导出失败 - 容器重启 - 磁盘 / 内存告警 输出： - 严重程度：信息 / 警告 / 错误 / 严重 - 主要发现 - 证据 - 疑似原因 - 建议下一步 - 是否需要人工处理 把报告写入 inbox/logs/log-triage-{today}.md。 不能修改生产配置。 不能删除日志。 ``` 处理规则： ```text 信息：归档 警告：进入技术债 错误：进入 inbox 严重：人工处理 ``` 核心判断： ```text 上线后，AI 不是继续写代码，而是开始值班。 ``` --- ## 节点 10：复盘沉淀 Pipeline 目标：把项目过程变成下一轮规则。 触发方式： ```text 每周五 每次 release 后 每次 incident 后 ``` 输入： ```text tasks/done inbox/test inbox/review inbox/deploy inbox/logs merged PR weekly commits ``` 输出： ```text reports/weekly/weekly-dev-review.md reports/release/release-postmortem.md reports/weekly/resume-bullets.md reports/weekly/interview-questions.md ``` 自动化 Prompt： ```text 使用 postmortem-skill。 生成每周开发复盘。 读取： - tasks/done/ - inbox/test/ - inbox/review/ - inbox/deploy/ - inbox/logs/ - 本周 git commits 输出： 1. 本周交付了什么 2. 哪些地方失败了 3. 还剩哪些风险 4. 下周应该修什么 5. AGENTS.md 哪些规则应该更新 6. 哪些 Skill 应该优化 7. 简历表达候选 8. 面试问题 9. 博客文章选题 不能修改源代码。 ``` 核心判断： **复盘不是写总结，而是把一次项目经验重新写进规则、Skill 和下一轮流水线。** --- ## 十、第五步：配置 Codex Automations（自动化） ### Automation 1：Daily Test Triage（24小时测试bug评审） 名称： ```text Daily Test Triage ``` 频率： ```text 每天 9:00 ``` Prompt： ```text 使用 test-triage-skill。 运行每日验证检查清单： 1. 检查 git status。 2. 如果最近修改了后端文件，运行后端测试。 3. 如果最近修改了前端文件，运行前端构建。 4. 如果修改了部署文件，检查 Docker Compose 配置。 5. 扫描最近 24 小时新增的 TODO / FIXME。 把报告写入 inbox/test/test-report-{today}.md。 如果所有检查通过，标记为“自动归档”。 如果有任何检查失败，标记为“需要人工查看”，并说明最小下一步。 不能修改源代码。 ``` --- ### Automation 2：Daily Log Triage（24小时日志审计） 名称： ```text Daily Log Triage ``` 频率： ```text 每天 10:00 ``` Prompt： ```text 使用 log-triage-skill。 分析最近 24 小时日志。 检查： - 后端错误 - 认证失败 - AI 调用失败 - 模型超时 - JSON 解析失败 - PDF 导出失败 - 容器重启 - Nginx 502 / 404 异常增长 把报告写入 inbox/logs/log-triage-{today}.md。 如果没有明显问题，标记为“自动归档”。 如果存在警告或错误，生成一份简短行动清单。 不能修改生产配置。 不能删除日志。 ``` --- ### Automation 3：Weekly Tech Debt Scan（7天技术债务扫描） 名称： ```text Weekly Tech Debt Scan ``` 频率： ```text 每周五 18:00 ``` Prompt： ```text 扫描项目技术债。 检查： 1. TODO / FIXME 2. 最近变更文件是否缺少测试 3. 文档是否过期 4. tasks/doing 中是否有长期未完成任务 5. 是否存在可疑重复代码 6. README 是否缺少关键部分 7. 部署文档是否和当前配置不一致 8. 风险项是否长期未解决 把报告写入 reports/weekly/tech-debt-{date}.md。 不能修改源代码。 只有当问题明确可执行时，才在 tasks/backlog/ 下创建任务建议。 ``` --- ### Automation 4：Weekly Dev Review（7天开发复盘） 名称： ```text Weekly Dev Review ``` 频率： ```text 每周日 21:00 ``` Prompt： ```text 使用 postmortem-skill。 基于以下内容生成每周复盘： - tasks/done/ - inbox/test/ - inbox/review/ - inbox/deploy/ - inbox/logs/ - 本周 git commits 输出： - 本周交付了什么 - 哪些地方失败了 - 还剩哪些风险 - 下周要做什么 - AGENTS.md 哪些规则应该更新 - 哪些 Skill 应该优化 - 简历表达候选 - 面试问题 - 博客文章选题 写入 reports/weekly/weekly-dev-review-{date}.md。 ``` 这 4 个自动化已经能覆盖： ```text 项目有没有坏 PR 能不能合 上线有没有风险 经验有没有沉淀 ``` 不要一上来配置 20 个 automation。 自动化越多，越需要治理。先把 MVP 跑通。 --- ## 十一、第六步：MCP 权限怎么控制 ### 建议安装的 MCP | 推荐顺序 | MCP | 是否建议第一版安装 | 主要解决什么问题 | 推荐权限 | 对应流水线阶段 | | ---- | ---------------------------- | --------- | --------------------------------- | ------------------------- | ---------------------- | | 1 | filesystem MCP | 建议安装 | 读取项目文档、任务卡、源码、报告、inbox | 限定项目目录；优先只读；源码修改必须走任务卡 | 需求判断、技术方案、任务拆解、测试巡检、复盘 | | 2 | GitHub MCP | 建议安装 | 读取 issue、PR、diff、review、仓库状态 | 第一版只读；写 PR 评论前需要确认 | 任务拆解、代码审查、PR 风险检查、复盘 | | 3 | browser / Playwright MCP | 建议安装 | 打开页面、检查白屏、截图、跑前端流程 | 仅开发环境或测试环境；禁止自动操作生产后台 | 原型设计、前端联调、冒烟测试 | | 4 | logs MCP / 日志读取工具 | 建议安装 | 读取后端日志、Nginx 日志、Docker 日志、AI 调用日志 | 只读；禁止删除日志；禁止修改配置 | 部署后巡检、每日日志排查、事故复盘 | | 5 | search / fetch MCP | 可选但推荐 | 查询官方文档、错误原因、依赖变更、竞品信息 | 只读；优先官方文档；搜索结果不能直接作为改代码依据 | 需求判断、技术调研、故障排查 | | 6 | database MCP | 谨慎安装 | 查询表结构、排查错误数据、辅助分析 SQL 问题 | 只读；优先开发库/测试库；禁止生产写入 | 技术方案、测试联调、日志排查 | | 7 | Figma MCP | 视项目而定 | 读取设计稿、辅助前端还原和 UI 审查 | 只读；不自动修改正式设计稿 | 原型设计、前端开发 | 不要一上来就给 AI： ```text 生产数据库写权限 服务器 root 权限 删除文件权限 部署生产权限 密钥读取权限 ``` 应该写清楚边界： ```text MCP 第一版只读优先。 任何写操作都必须人工确认。 生产环境默认不允许 AI 直连写入。 数据库、密钥、部署、删除、迁移必须标记为仅人工处理。 ``` MCP 的价值不是让 AI 权限更大，而是让 AI 在受控边界内拿到更真实的上下文。有了边界，MCP 才能真正把编码Agent从“写代码工具”变成“后台开发助理”。 最后验收： ## 真实可用验收清单 搭完以后，不要只看目录有没有创建，要检查是否真的能识别和运行。 ```text [ ] Skill 是否放在 .agents/skills/ 下 [ ] 每个 Skill 是否都有 SKILL.md [ ] 每个 SKILL.md 是否有 name 和 description [ ] 在 Codex 输入 $ 时，是否能看到对应 Skill [ ] Automation Prompt 是否显式使用 $skill-name [ ] Automation 是否选择了正确项目 [ ] Git 仓库里的 Automation 是否优先使用 worktree 隔离 [ ] inbox/ 是否能收到自动化结果 [ ] GitHub PR Review 是使用 @codex review，还是 GitHub Action，二者是否讲清楚 [ ] GitHub Action 是否配置 OPENAI_API_KEY [ ] AGENTS.md 是否写了 Review guidelines [ ] MCP 是否只开放必要权限 [ ] 部署、数据库、密钥、删除操作是否明确标记 manual_only ``` --- ## 十二、这套流程怎么写进简历？ 不要只写： ```text 熟练使用 Codex / Claude Code / Cursor 辅助开发。 ``` 可以写成： 设计并实践 AI 项目交付流水线，基于 Codex Automations、AGENTS.md、Agent Skills、MCP 和 GitHub PR Review，将测试巡检、PR 风险审查、部署前检查、日志排查和复盘沉淀等环节结构化为可触发、可追踪、可审批的工程流程。通过 AI Dev Inbox 统一收口自动化发现的问题，并按“自动归档 / 需要人工查看 / 创建任务 / 需要人工处理”分流，降低 AI 编程中的无序修改、重复排查和上线风险。 如果面试官问： > 这不就是会用 AI 工具吗？ 可以这样回答： 不是。我做的不是单点 AI 编程，而是把 AI 能力放进软件工程流水线。每个阶段都有输入、触发器、产物、风险等级和人工 Gate。比如测试巡检可以定时触发，PR 审查可以事件触发，部署检查必须人工确认，日志排查会进入 inbox，复盘会反向更新 AGENTS.md 和 Skill。AI 负责重复检查、初稿生成和低风险执行，人负责方向判断、审批和上线结果。 这就不是“会用工具”，这是“会设计 AI 工程流程”。 --- ## 十三、总结：AI 工作流真正值钱的地方 如果只会让 AI 写代码，门槛会越来越低。 真正有价值的是你能不能回答这些问题： ```text AI 在什么时候介入？ 它读什么上下文？ 它调用什么工具？ 它输出什么产物？ 它能不能改代码？ 它能改哪些文件？ 它改完怎么验证？ 它什么时候必须停下来等人？ 它的发现进入哪里？ 它的经验怎么沉淀到下一轮？ ``` 这就是我理解的 AI 工作流一体化。 不是让 AI 替我从 0 到 1 做完项目。 而是把 AI 放进一个有边界、有触发、有产物、有审批、有复盘的软件工程流水线里。 最后再重复这 4 句话： **AI 编程的下一步，不是更长的 Prompt，而是更清晰的工程边界。** **AI 不应该直接接管项目，而应该进入有触发、有产物、有审批的流水线。** **能自动化的是巡检、整理、初稿、检查和低风险修复；不能自动化的是方向判断、风险审批和上线责任。** **真正有价值的 AI 工作流，不是让 AI 多写一点代码，而是让项目过程变得可追踪、可审查、可复盘。** 这就是我这套 AI 项目交付流水线真正的价值。 我是Ryan，记录真实的AI应用工程，下一篇文章分享我用Codex从立项到完整构建项目的全流程经验。 跨境电商客服项目(进行中）：[OmniMerchant](https://github.com/RyanCoreAI/spring-ai-crossborder-customer-service)