#架构设计

5天前

ClawHub Skills 排名第一的「self-improving-agent」：记录经验、总结错误，形成持久化的经验记忆，提取成 Skills，自我提升，不断总结经验，这个 Skills 的设计理念真的很值得反复琢磨。 - 架构分为三层 - 第一层：日志采集在项目根目录下建立 .learnings/ 目录，包含三类文件： · LEARNINGS.md：被用户纠正的错误认知、过时的知识、更优的做法 · ERRORS.md：命令执行失败、异常堆栈、意外行为 · FEATURE_REQUESTS.md：用户希望 Agent 具备但目前缺失的能力每条记录采用统一的结构化格式：唯一 ID、时间戳、优先级、状态、涉及的代码区域、详细描述、建议修复方案，以及用于关联相似问题的 See Also 字段。第二层：经验晋升日志只是原始材料。当某条经验被验证为普遍适用——不是一次性的个案，而是跨文件、跨功能的通用规则——就应该"晋升"到更高层级的配置文件中： · CLAUDE.md / .github/copilot-instructions.md：项目级的事实和约定，所有 Agents 会话都会读取 · AGENTS.md：Multi Agents 协作的工作流规则 · SOUL.md：OpenClaw 行为准则和沟通风格 · TOOLS.md：工具使用的注意事项和已知坑点晋升时要求提炼，不是把冗长的事故报告搬过去，而是压缩成简短的防御性规则。比如： > 原始记录：项目用 pnpm workspaces，我试了 npm install 结果失败了，锁文件是 pnpm-lock.yaml，必须用 pnpm install。 > 晋升后写入 CLAUDE.md：Package manager: pnpm (not npm) - use pnpm install 这个从"事故叙述"到"行为规则"的转化过程，是整个 Skills 最有价值的设计。第三层：Skill 提取当某条经验足够通用——不仅对当前项目有用，对其他项目也有参考价值——可以进一步提取为独立的 Skill。Skill 提供了一个 extract-skill. sh 脚本来辅助这个过程，支持 --dry-run 预览。提取的门槛设得比较合理：需要有 2 个以上的关联条目（说明是反复出现的问题）、已验证的修复方案、非显而易见的知识点。 - 自动化机制 - Skills 提供了两个 Hook 脚本，通过 Agent 的钩子系统实现半自动化： · activator. sh（挂载在 UserPromptSubmit）：每次用户发送消息后注入一段提醒，让 Agent 评估是否需要记录经验。开销约 50-100 tokens。 · error-detector. sh（挂载在 PostToolUse）：监听 Bash 命令执行结果，当检测到非零退出码时触发记录流程。 - 循环模式检测 - Skills 专门设计了一套去重和升级机制来处理反复出现的同类问题： · 每条记录可以带 Pattern-Key（如 simplify.dead_code、harden.input_validation）作为稳定的去重键 · 同一 Pattern-Key 再次出现时，递增 Recurrence-Count，更新 Last-Seen · 当一个模式满足出现 3 次以上 + 跨 2 个以上任务 + 30 天内这三个条件时，自动触发晋升这个量化的晋升规则避免了两个极端：过早晋升导致配置文件膨胀，或过晚晋升导致同样的错误不断重复。 - 多个 AI Agents 兼容性 - · Claude Code / Codex：通过 Hook 脚本激活 · OpenClaw：通过 Workspace 注入 + 会话间通信激活 · GitHub Copilot：手动写入 instructions OpenClaw 平台的集成最深，支持通过 sessions_send 在不同会话之间传递经验，这意味着一个会话踩过的坑可以实时通知到并行运行的其他会话。 Skills 安装地址

#self-improving-agent #ClawHub Skills #经验记忆 #架构设计

4个月前

AI对初级前端人员的摧毁是很大的，AI的前端代码生成速度快，而且代码规整还带文档前端开发要花更多时间去超越AI的初级能力才能找到工作我对前端人员的建议： 1. 把CSS/SVG的基础打好：AI擅长做组件，但是复杂布局的样式冲突和精巧的动画还是不如人类 2. 学学架构设计：AI的代码能工作，但是废代码也很多，架构能力强了，能更好的驾驭复杂软件，真正商业软件都是复杂的，而不是AI生成的那些Demo 3. 多运动：你多运动就会开朗很多，这样沟通能力就增强了，AI再强了，他也不能去和普通人沟通需求 AI来了是新人杀手，也是机会，就看怎么转变了

#AI前端开发 #CSS/SVG基础 #架构设计 #沟通能力 #前端人员

4个月前

我现在是 Agent 信徒 + 手搓，Tab 反而最少 1. 先用 Agent 快速实现完整功能，不必在意质量，但核心是完整实现需求，走通各个流程，了解各种边界条件 2. 然后基于需求和完整的流程，重新思考设计架构，再手搓+Agent 这样既可以兼顾速度，又可以保证质量

#agent #手搓 #效率 #架构设计 #软件开发

6个月前

前一段时间有人问我怎么系统的学习前端。我最近感触很深的是，很多东西过了多少年依旧没有变，比如我面过人类学的前端架构，里面问到的问题依然是2020年Slack的架构设计的博客内容。即使是在AI时代，nothing is new：SSE、websocket……甚至正因为有了AI，很多设计模式来控制复杂度变得尤为重要。所以我觉得当今人应该更多放在整体的架构设计和代码复杂度控制。所以我觉得付费给一些很无聊的人讲怎么vibe coding是很囫囵吞枣的事情，我觉得有很多人靠着贩卖焦虑来获得流量和收入，但我觉得有些事情是必须“纸上得来终觉浅，绝知此事要躬行”

#前端学习 #架构设计 #代码复杂度控制 #贩卖焦虑 #实践的重要性

7个月前

分享一个Claude Code全局提示词（也适用于Augment/Cursor等等），有架构师附身之奇效： ## Code Architecture - 编写代码的硬性指标，包括以下原则：（1）对于 Python、JavaScript、TypeScript 等动态语言，尽可能确保每个代码文件不要超过 200 行（2）对于 Java、Go、Rust 等静态语言，尽可能确保每个代码文件不要超过 250 行（3）每层文件夹中的文件，尽可能不超过 8 个。如有超过，需要规划为多层子文件夹 - 除了硬性指标以外，还需要时刻关注优雅的架构设计，避免出现以下可能侵蚀我们代码质量的「坏味道」：（1）僵化 (Rigidity): 系统难以变更，任何微小的改动都会引发一连串的连锁修改。（2）冗余 (Redundancy): 同样的代码逻辑在多处重复出现，导致维护困难且容易产生不一致。（3）循环依赖 (Circular Dependency): 两个或多个模块互相纠缠，形成无法解耦的“死结”，导致难以测试与复用。（4）脆弱性 (Fragility): 对代码一处的修改，导致了系统中其他看似无关部分功能的意外损坏。（5）晦涩性 (Obscurity): 代码意图不明，结构混乱，导致阅读者难以理解其功能和设计。（6）数据泥团 (Data Clump): 多个数据项总是一起出现在不同方法的参数中，暗示着它们应该被组合成一个独立的对象。（7）不必要的复杂性 (Needless Complexity): 用“杀牛刀”去解决“杀鸡”的问题，过度设计使系统变得臃肿且难以理解。 - 【非常重要！！】无论是你自己编写代码，还是阅读或审核他人代码时，都要严格遵守上述硬性指标，以及时刻关注优雅的架构设计。 - 【非常重要！！】无论何时，一旦你识别出那些可能侵蚀我们代码质量的「坏味道」，都应当立即询问用户是否需要优化，并给出合理的优化建议。

AI编程工具激战：Claude Code、Gemini Cli崛起· 1256 条信息

#代码架构 #代码质量 #代码优化 #坏味道 #架构设计

9个月前

分享几张图： 1. 第一张是我设计EAF开源项目时，我家黑板上的架构图 2. 第二张是懒猫微服早期硬件白板三维图 3. 第三张是设计 lsp-bridge 的架构图所有的架构设计都源于三个事情： 1. 精准的知道自己要什么 2. 整体架构流程要思路清晰 3. 锻炼自己的复杂思维能力我每次做复杂开源项目的时候，我都会做三件事： 1. 问自己几个月，是否真的想要做这个，所有需求是什么？哪些是真实需求，哪些是伪需求？ 2. 在白板或者白纸上徒手画架构图，所有工程难点都先假设自己已经完成，纯粹画全景图，如果全景图画不出来，就证明自己脑袋是一片糨糊 3. 当架构图全部画清楚以后，我会反复的质疑我自己的架构图，直到所有伪代码已经在我脑袋运行千百遍以后，没有任何bug，我再写代码真正写代码的时候，就像第一张图一样，看着黑板的图，一个一个的写实现，写完一个擦一块，直到摩天大楼像预期一样分毫不差的实现。

#EAF开源项目 #架构设计 #懒猫微服 #lsp-bridge #复杂思维 #开源项目