最近在尝试用 AI 生成 Excel 和 Word 折腾了一圈发现效果不太行，我日常主要是用 opencode 和 codex ，现在想通过加 skills 的形式解放 office 能力 但是折腾了一阵发现效果很差，很多时候甚至不如网页免费的 AI 来的好，想问问 v 友有没有什么推荐的方案
最近在尝试用 AI 生成 Excel 和 Word 折腾了一圈发现效果不太行，我日常主要是用 opencode 和 codex ，现在想通过加 skills 的形式解放 office 能力 但是折腾了一阵发现效果很差，很多时候甚至不如网页免费的 AI 来的好，想问问 v 友有没有什么推荐的方案
前言 目前我把游戏分别放在本地 D:\game 和NAS的 G:\game （映射盘符）上运行(主要是gal和一些SLG太占空间了,又不想删)。长时间后, Local,Roaming,LocalLow 里会有各种游戏生成的存档和配置文件目录。 删游戏时这些目录并不会自动消失，AppData 越来越臃肿，想手动清理又怕删错，备份更是无从下手 于是我写了一套 PowerShell 脚本： 实时监控文件夹创建，自动记录游戏路径和存档位置，并在确认后将存档迁移到统一目录，在原位置留下符号链接 。这样既能把存档集中管理，又能让 AppData 保持干净。不过，NAS 映射盘符是整个过程里最大的坑（但大多佬们似乎用不到）。本文将分享我从“映射失败”到“稳定挂载”的全过程，以及脚本在中文转码、路径匹配、去重、队列管理等方面踩过的坑和最终方案。 而且我现在的环境很特殊：NAS 和主机用网线直连，主机通过 ICS 让 NAS 共享校园网。下一篇博客会补充 NAS 实战中的更多内容(为此我花了一周在学习网络通信协议)。 手动查找并迁移已有文件 1. 按修改时间查找文件 如果知道文件大概的修改时间范围，可以用以下命令快速定位： Get-ChildItem -Path "D:\game" -Recurse -File | Where-Object { $_.LastWriteTime -ge "2026-06-01 10:40" -and $_.LastWriteTime -le "2026-06-01 11:00" } 找到后根据完整路径判断属于哪个游戏，然后手动复制存档到备份目录（例如 D:\GameSaves\manual ）。 2. 批量迁移脚本（BAT 示例） 对于大量已知映射关系的配置文件，可以写一个批处理脚本。 注意：BAT 脚本如需输出中文，必须保存为 ANSI(GBK) 编码；而给 AI 或代码库看的脚本建议用 UTF-8。 @echo off set SRC1=C:\Users\admin\AppData\Local\GameA\Save set DST1=D:\GameSaves\GameA xcopy "%SRC1%" "%DST1%" /E /I /Y set SRC2=C:\Users\admin\AppData\LocalLow\GameB set DST2=D:\GameSaves\GameB xcopy "%SRC2%" "%DST2%" /E /I /Y echo 迁移完成 pause NAS 盘符映射 1. 在 Windows 中映射 NAS 文件夹 我的 NAS 型号是绿联 Dxp4800plus，通过 ICS 共享网络，设置的私网IP 为 192.168.137.20 。我把所有游戏放在 NAS 共享文件夹 ACG （原名 acg资源 ，后来改名）下，并映射到主机的 G: 盘。 正确映射方法（一定要勾选“登录时重新连接”） ： 右键“此电脑” → “映射网络驱动器”。 驱动器选择 G: ,文件夹选择 NAS设备\ACG 必须勾选"登录时重新连接" ，不然后面开机自启会出问题。 用校园网连接NAS时，在 网络 可能会找不到设备，需要先进入 WLAN 把校园网从专用切换为公用，再在 网络 里重新转为专用，才能发现 NAS 设备。我现在也没搞清楚根本原因是什么，如果佬们知道正确的修改方法请告诉我。 2. 几个踩坑点 踩坑 1：修改共享名称后映射失效 当我把共享文件夹从 acg资源 改名为 ACG 后，就无法进入之前映射好的 G: 盘了。这是因为映射驱动器指向的远程路径是 \\...\acg资源 ，而实际共享已不存在。 解决方法 ： 先删除旧映射G盘 按照上述步骤重新映射到新文件夹 ACG 一旦修改 NAS 共享名，必须同时更新所有客户端的映射，并更新脚本中的路径 踩坑 2：到底该用盘符（G:）还是 UNC 路径（\IP\share）? 这是困扰我最久的问题(主要是不停打开游戏和脚本测试,还要不断删除对应的文件和json内容)。 脚本需要匹配运行中游戏的可执行文件路径，而 Get-Process 返回的 Path 属性 在不同启动方式下表现不一致 ： 如果通过资源管理器双击 G:\game\xxx.exe 启动，进程路径有时是 G:\game\... （盘符形式）。 如果通过 \\192.168.137.20\ACG\game\xxx.exe 直接启动，进程路径是 UNC。 有些游戏启动器可能会强制转换路径。 我最初按 UNC 路径 \\192.168.137.20\ACG\game 设置 $gameRoot ，但实际运行时却匹配不到（因为进程路径是 G:\game 开头）。后来改为 G:\game 就成功了,所以最稳妥的做法是 把盘符和UNC都配置上 ，让脚本自己去匹配。 不知道为什么，在 powershell 中 cd \\192.168.137.20\ACG\game 却没有问题 踩坑 3：开机自启时 G 盘还未连上 设置任务计划程序开机启动脚本后，发现脚本虽然运行了，但始终检测不到 NAS 上的游戏。日志显示 [注意] 未检测到游戏进程 。 原因：用户登录后，系统需要几秒钟来恢复网络驱动器。而脚本在登录瞬间就执行了，此时 G: 盘还不存在。 解决方案 ：在任务计划程序的触发器设置中，添加 “延迟任务时间 30 秒” （或更长，如 60 秒），这样脚本会等待网络和映射完全准备好再启动。 实现自动化监控脚本 核心需求： 监控三个存档常用目录： %LOCALAPPDATA% 、 %APPDATA% 、 %USERPROFILE%\AppData\LocalLow （即 Local,Roaming,LocalLow ） 当有新文件夹被创建（某个游戏第一次生成存档）时，自动记录 同时检查本地 D:\game 和 NAS 映射的 G:\game 路径，检测当前运行的游戏进程并将其 exe 路径以 Base64 存入队列 1. 设置 PowerShell 执行策略 首次运行脚本前，需要允许执行本地脚本： Set-ExecutionPolicy RemoteSigned -Scope CurrentUser 2. 监控脚本（Watch-GameSaves.ps1） 以下为脚本核心结构（完整代码略去，仅说明逻辑）： 定义监控根目录、排除文件夹列表。 使用 FileSystemWatcher 监视 $watchPaths 下的文件夹创建事件。 事件触发后： 跳过已存在的连接点或排除文件夹。 延迟 3 秒，给游戏时间完成写入。 获取正在运行的进程，匹配路径是否以 D:\game 或 G:\game 开头。 将匹配到的第一个游戏 exe 路径转为 Base64（避免 JSON 中的转义和乱码问题）。 将存档路径、游戏 exe Base64、时间等信息写入 pending.json 。 3. 解决中文乱码：Base64 转码 因为游戏路径中可能出现中文（如“除灵猎人”），直接存储到 JSON 会导致编码混乱（而且很难解决，不论将文件保存为UTF-8还是GBK都不行，因为本质是在action中进行的解码）。解决方法是将 exe 路径进行 Base64 编码： { "srcPath": "C:\\Users\\admin\\AppData\\Local\\NebelTR", "time": "2026-06-04 15:28:26", "gameExeBase64": "RDpcZ2FtZVxSUEdcQkJR5aSn5aW944GNXOmZpOeBteeMjuS6ulzpmaTngbXnjI7kurotQ04tMS4xMlxHYW1lLmV4ZQ==", "dirName": "NebelTR", "remark": "" } 使用时通过 [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($base64)) 解码即可得到原始中文路径。 4. 避免重复记录已处理目录 某个存档目录已经成功迁移并创建了符号链接后，之后游戏再次运行，监控脚本又检测到同一目录的“创建”事件，就会导致重复记录。 解决方法 ：在向 pending.json 追加新条目之前，先检查队列中是否已存在相同的 srcPath 。若有，直接跳过，不重复添加。这样即使链接目录被误触创建事件，也不会污染队列，同时也避免了后续转移脚本重复处理。 转移脚本与队列处理 监控是持续运行的，迁移则是定期手动触发（比如一个月或半年一次）。转移脚本读取 pending.json ，把存档从 AppData 搬走，原地建符号链接。 1. 转移脚本设计要点 从 pending.json 读取待处理项。 对每一项，先确定目标目录名。优先使用手动填写的 remark ，否则从解码后的 exe 路径自动提取游戏文件夹名，若都失败则回退到原始目录名。 通过 robocopy 将源目录完整复制到 D:\GameSaves\目标名 。 复制成功后， 删除源目录 ，并在同一位置创建一个 目录链接 指向新路径。 将迁移关系记录到 Markdown 格式的日志文件 存档迁移记录.md 中。 处理成功的条目从队列移除，失败则保留，等待下次重试。 2. 几个关键设计 安全删除和链接创建 ，这是最容易翻车的环节，有两个点必须处理好： 复制前如果目标目录已存在 （比如之前迁移过但记录丢了），直接 robocopy 会合并文件，可能造成新旧存档混杂。必须先尝试删除已有目标目录，并 检查是否真的被删干净 ；若因文件占用无法完全删除，则中止本次操作，保留队列项。 复制后删除源目录时，同样可能因文件占用导致部分删除失败 。必须确认源目录已完全消失后，才能创建链接。否则残留目录加上失败的链接创建，会让游戏存档状态混乱。若删除失败，整个迁移视为未完成，保留在队列中,下次重试。 这些检查在脚本中都是以条件判断 + 日志记录的方式实现的，确保一定成功。 迁移记录以 Markdown 表格形式写入 存档迁移记录.md ，例如: 原 C 盘快捷方式名 实际存储位置 游戏/说明 praygame D:\GameSaves\祈愿游戏 praygame 游戏存档 rmmz-game D:\GameSaves\莉可的不可思议差事 莉可的不可思议差事 这样无论后续手动浏览还是用其他工具解析，都非常直观。 队列自动清理 ：每处理完一批，脚本生成一个新的 JSON 数组，只包含失败的项，覆盖写回 pending.json 。成功的自动消失，不需要手动编辑。 设置开机自启 使用 Windows 任务计划程序保证脚本在每次登录时自动运行。 操作步骤 打开“任务计划程序” （可以 Win+R 输入 taskschd.msc ）。 右侧点击 “创建任务” （不是“创建基本任务”）。 名称： GameSavesMonitor 配置： Windows 10 ，勾选 “使用最高权限运行” 。 触发器 → 新建： 开始任务： 登录时 特定用户：选择你的账户（如 DESKTOP-XXX\admin ） 高级设置： 延迟任务时间 30 秒 （给网络驱动器映射留出时间） 确保“已启用”被勾选。 操作 → 新建： 程序或脚本： powershell.exe 添加参数： -WindowStyle Hidden -ExecutionPolicy Bypass -File "D:\Scripts\Watch-GameSaves.ps1" 起始于（可选）： D:\Scripts 条件 ：建议取消“只有在计算机使用交流电源时才启动此任务”（笔记本）。 设置 ：勾选“如果任务失败，按以下频率重新启动”（间隔 1 分钟，最多 3 次）。 确定保存。 验证自启是否生效 重启电脑后登录， Win+R 输入 taskschd.msc 查看 显示所有正在运行的任务 。 检查日志文件 D:\GameSaves\监控调试日志.txt ，应包含最新的启动时间戳。 总结 通过这套方案，无论游戏安装在本地还是 NAS，只要启动游戏产生配置文件夹，脚本就会自动记录存档路径和对应的游戏 exe 位置（Base64 编码）,并利用任务计划程序实现开机自启，再配合手动或自动迁移脚本，基本可以保证AppData较为干净。 由于所有操作都在 AppData 内进行（删除、创建链接）， 直接贴出完整脚本容易导致佬们在不理解的情况下误操作，造成数据丢失 。因此本文只讲逻辑和关键点，佬们可以根据以上思路自行编写，或让 AI 辅助生成。真有需要的佬可以私信我，如果对某一块的实现细节感兴趣，也欢迎留言交流。 2 个帖子 - 2 位参与者 阅读完整话题
打磨了很久的文章，鉴于使用了ai润色，所以截图发出，各位佬友看看算不算得上干货，相较大众认知应该能先进一些吧。 4 个帖子 - 3 位参与者 阅读完整话题
（我不知道招谁惹谁了，怎么这么多人不依不挠，求你别看我的帖子了！） 如果你曾经买过过气服务区的老号，你会发现原来氪金了10万的号只要几千就可以掌握了，那么你会干什么呢？ 养小号！ 如果你一不小心满级英雄技能点歪了，你会怎么做呢？ 养小号！ 对了，这个就是AGI的目前最佳的路线图。 世界上主要的派别有18家，我姑且把我定义为第19家（当然你也可以是，只要你能说出个一二三来） LLM是一个被点歪了的AGI，他估计这辈子也长不成AGI，但是可以把他当作一个大号用（而且还是巨便宜那种） 但是你想做成AGI，有几个核心的问题你必须解决。 你的最原始的0-1，1-2， 2-3， 3-N （N可以趋于无穷大）的那个0，1，2，3到底是什么，有没有想明白。 目前来看，前18家里有大家耳熟能详的大厂，也有一些大家不怎么在意（也远远没有LLM那么火） 实际上LLM已经基本上到了一个快尘埃落地的时候了。 但是LLM最后会变成基础设施，而绝对不会变成AGI，这是由其的基于统计的本质所决定的。 所以第一步是加上很多外设，让各种统计基于规范的路由规则来展现，就能表现出一定的智商。 （我也做了一个，怎么说呢，对我自己比较有用，对别人没有用，因为底层逻辑就和别人不一样） 第二步则是不要由人脑来控制和设计这些路由规范，而是基于一个本地的微缩版LLM（曾经google还是deepmind有一篇论文说解决了上下文扩充的内存消耗问题，从而马斯克的光纤当内存的怪异但符合第一性原理的设想未能实施-也许已经在实施），同时整合上述的高级元路由规则，再结合最关键的一个（真实物理世界反馈） 则基本就能达到了初级AGI了（看上去是） 第三步有赖于更进一步的升级内核 正如opencode的源码才几百K一样，实际上现在计算机不能AGI的最大问题是二进制，实际上三进制才是更能符合AGI的。但是，目前从零研发三进制的硬件＋软件成本太高。 但是未来量子计算机、生物计算芯片和更一步泛滥的LLM “ｔｏｋｅｎ智力”，有望快速做出原型脑芯片。 届时，０.１ｂｅｔａ版的AGI就将成功。 然后，０.１版的将碾压一切LLM和０.１之下的AGI路线图。 1 个帖子 - 1 位参与者 阅读完整话题
想推荐国模给朋友使用，有没有佬友分享下国模的使用心得 工作内容偏向前端 是GLM还是Mimo还是Deepseek，怎么接会比较方便呢 4 个帖子 - 3 位参与者 阅读完整话题
高考结束了，预祝参加高考以及小孩高考的佬们金榜题名，上个好学校。小孩也准备高三了，也是蛮幸苦的了，作为大人也想好好帮助她提升下学习成绩。所以想求下各位佬，有用AI来辅助复习实践的经验能否传授下，或者各位佬按自己的想法有什么样的好建议，想通过vibe coding来帮忙实现vibe revise，谢谢 5 个帖子 - 4 位参与者 阅读完整话题
我这边用hermes接入mimo模型，用起来感觉还好，是一键绿色部署的，但是升级agent后感觉会降智，有没有朋友用过分享一下心得 1 个帖子 - 1 位参与者 阅读完整话题
前言 最近我在开发一个基于 Plasmo 的 Chrome MV3 浏览器扩展，项目主要用于统一管理 ChatGPT、Claude 等 AI 平台的对话记录，支持账号同步、搜索、收藏、标签、批量操作等功能。 随着功能逐渐完善，扩展里出现了大量 UI 文案、提示信息、错误信息。如果这些文本全部硬编码在组件里，后续维护会非常麻烦： 想支持英文、中文等多语言时，需要到处改代码； popup、content script、background 里都有文案，容易遗漏； Chrome 扩展本身也有名称、描述等 manifest 文案，也需要国际化； 文案带变量时，比如“已选中 5 项”，如果手动拼接，会不利于多语言适配。 因此，我最终使用 Chrome 扩展原生提供的 chrome.i18n API，再结合 Plasmo 的目录约定，给项目做了一套轻量、简单、够用的国际化方案。 本文就结合我的项目实践，介绍如何在 Plasmo 浏览器扩展中实现 i18n。 一、项目技术栈 我的项目是一个 Chrome MV3 扩展，主要技术栈如下： Plasmo React TypeScript Tailwind CSS Chrome Extension Manifest V3 项目结构比较简单，所有源文件都放在项目根目录，没有额外的 src 目录。 核心文件大致如下： my-first-extension/ ├── popup.tsx ├── content.ts ├── background.ts ├── logic.ts ├── db.ts ├── utils/ │ └── i18n.ts ├── locales/ │ ├── en/ │ │ └── messages.json │ └── zh_CN/ │ └── messages.json ├── package.json └── ... 其中和国际化相关的主要是： utils/i18n.ts locales/en/messages.json locales/zh_CN/messages.json package.json 二、Plasmo 项目中的语言包目录 在 Chrome 扩展规范中，最终构建产物里通常会有 _locales 目录，例如： _locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json 而在 Plasmo 项目开发阶段，我们可以直接在项目中创建： locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json Plasmo 构建时会处理这些语言资源，让它们符合 Chrome Extension 的国际化规范。 我的项目里目前支持两种语言： locales/en/messages.json locales/zh_CN/messages.json 其中： en 是英文； zh_CN 是简体中文。 三、在 manifest 中配置默认语言 Chrome 扩展要启用国际化，必须在 manifest 中声明 default_locale 。 在 Plasmo 项目里，可以直接在 package.json 的 manifest 字段里配置： { "manifest": { "default_locale": "en", "permissions": [ "storage", "alarms" ], "host_permissions": [ "https://chatgpt.com/*", "https://claude.ai/*" ] } } 这里我把默认语言设置为英文： "default_locale": "en" 这意味着如果用户当前浏览器语言没有对应的语言包，Chrome 会回退使用英文语言包。 四、扩展名称和描述的国际化 浏览器扩展的名称、描述也可以使用 Chrome i18n 的占位符语法。 我的 package.json 中这样写： { "name": "multi-ai-conversation-manager", "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" } 这里的重点是： "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" __MSG_xxx__ 是 Chrome 扩展国际化的特殊语法。 例如： __MSG_extName__ 会去当前语言包的 messages.json 中查找： { "extName": { "message": "ChatGPT & Claude AI Conversation Manager" } } 中文语言包中对应的是： { "extName": { "message": "ChatGPT、Claude AI 对话管理器" } } 这样一来，扩展在 Chrome 扩展管理页、商店信息或者 manifest 中展示时，就能根据用户浏览器语言自动切换名称和描述。 五、messages.json 的基本格式 Chrome 扩展的语言文件必须叫做 messages.json 。 基本格式如下： { "key": { "message": "具体文案" } } 比如英文语言包： { "account_management": { "message": "Account Management" }, "account_add": { "message": "Add Account" }, "btn_confirm": { "message": "Confirm" }, "btn_cancel": { "message": "Cancel" } } 中文语言包： { "account_management": { "message": "账号管理" }, "account_add": { "message": "添加账号" }, "btn_confirm": { "message": "确认" }, "btn_cancel": { "message": "取消" } } 这里需要注意： 不同语言包里的 key 要保持一致。 也就是说，英文里有： "account_add" 中文里也必须有： "account_add" 否则运行时调用这个 key 时，某些语言环境下就可能取不到翻译。 六、封装一个统一的 t 函数 虽然可以在代码里直接写： chrome.i18n.getMessage("btn_confirm") 但如果项目中大量使用这个 API，会有几个问题： 写起来比较长； 后续如果想增加 fallback 逻辑，需要到处改； popup、content script、background 都会重复使用； 不方便统一处理参数替换。 所以我在项目中封装了一个简单的工具函数。 文件位置： utils/i18n.ts 代码如下： /** * Chrome 扩展国际化工具函数 * 封装 chrome.i18n API，提供类型安全的文本获取方法 */ /** * 获取国际化文本 * @param key - messages.json 中定义的 key * @param substitutions - 可选的替换参数，字符串或字符串数组 * @returns 翻译后的文本，如果 key 不存在则返回 key 本身 */ export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 这个函数做了两件事： 第一，简化调用： t("btn_confirm") 比下面这样更简洁： chrome.i18n.getMessage("btn_confirm") 第二，增加 fallback： return chrome.i18n.getMessage(key, substitutions) || key 如果某个 key 没有找到，直接返回 key 本身。这样至少页面不会显示空字符串，调试时也很容易发现哪个 key 没配置。 七、在 React Popup 页面中使用 i18n 我的扩展主要 UI 在 popup.tsx 中，它是一个 React 页面。 首先引入工具函数： import { t } from "./utils/i18n" 然后就可以在 JSX 中使用： <button> {t("account_add")} </button> 或者用于错误提示： return ( <div className="p-4 text-red-500 text-sm"> {t("errorBoundaryMessage")} </div> ) 对应的英文语言包： { "errorBoundaryMessage": { "message": "An error occurred. Please close and reopen the extension" } } 对应的中文语言包： { "errorBoundaryMessage": { "message": "出现错误，请关闭后重新打开扩展" } } 这样，当用户浏览器语言是中文时，会显示中文；如果是英文环境，则显示英文。 八、在 Content Script 中使用 i18n 浏览器扩展不仅 popup 页面需要国际化，content script 也经常需要显示文案。 我的项目中， content.ts 会注入到 ChatGPT 或 Claude 页面中，用于检测当前登录账号。如果发现新账号，会在页面右下角显示一个提示卡片，引导用户同步账号。 同样先引入： import { t } from "./utils/i18n" 然后在创建 DOM 时使用： card.innerHTML = ` <button class="close-btn" aria-label="${t('content_closeAriaLabel')}">×</button> <div class="header"> <div class="text-content"> <h3>${t('content_newAccountTitle')}</h3> <p>${t('content_newAccountDesc', platformName)}</p> </div> </div> <div class="actions"> <button class="btn-ignore">${t('content_btnIgnore')}</button> <button class="btn-add">${t('content_btnSync')}</button> </div> ` 这里有一个带变量的文案： t("content_newAccountDesc", platformName) 比如英文里可能是： { "content_newAccountDesc": { "message": "A new $PLATFORM$ account was detected. Do you want to sync it now?", "placeholders": { "platform": { "content": "$1", "example": "ChatGPT" } } } } 中文里可以是： { "content_newAccountDesc": { "message": "检测到新的 $PLATFORM$ 账号，是否立即同步？", "placeholders": { "platform": { "content": "$1", "example": "ChatGPT" } } } } 这样在代码里只需要传入平台名称： t("content_newAccountDesc", "ChatGPT") 最终 Chrome 会自动把 $1 对应的内容替换进去。 九、在 Background 和业务逻辑中使用 i18n 除了 UI，后台逻辑里也会产生提示信息或错误信息。 比如消息处理器、同步逻辑、错误封装中，也可以统一使用： import { t } from "~utils/i18n" 或： import { t } from "./utils/i18n" 然后： throw new Error(t("error_accountMismatch")) 或者： return { success: false, error: t("error_syncFailed") } 这样有一个好处： 前端展示的错误信息和后台返回的错误信息，都可以使用同一套语言包管理。 对于浏览器扩展来说，popup、content script、background 是不同运行环境，如果不统一管理文案，后期维护会很痛苦。 十、带参数文案的写法 国际化里最常见的问题之一，就是文案里带变量。 比如： 已选中 5 项 不能简单写成： "已选中 " + count + " 项" 因为不同语言的语序可能不一样。 正确做法是放到语言包中： 英文： { "batch_selectedCount": { "message": "$COUNT$ items selected", "placeholders": { "count": { "content": "$1", "example": "5" } } } } 中文： { "batch_selectedCount": { "message": "已选中 $COUNT$ 项", "placeholders": { "count": { "content": "$1", "example": "5" } } } } 代码中调用： t("batch_selectedCount", String(selectedCount)) 如果有多个参数，也可以传数组： t("error_accountMismatch", [oldEmail, newEmail]) 语言包中可以使用： { "error_accountMismatch": { "message": "账号不匹配：当前账号是 $CURRENT$，目标账号是 $TARGET$", "placeholders": { "current": { "content": "$1", "example": "[email protected]" }, "target": { "content": "$2", "example": "[email protected]" } } } } 十一、推荐的 key 命名方式 随着项目变大，语言包会越来越长。如果 key 命名不规范，很容易混乱。 我在项目中采用了按业务模块前缀命名的方式，例如： theme_light theme_dark theme_system account_management account_add account_delete account_sync batch_manage batch_addTag batch_removeTag batch_selectedCount tag_management tag_create tag_rename tag_delete conversation_notFound conversation_total conversation_copyLink content_newAccountTitle content_newAccountDesc content_btnIgnore content_btnSync errorBoundaryMessage error_syncFailed 这种命名方式有几个优点： 一眼能看出文案属于哪个模块； 搜索方便； 不容易和其他模块冲突； 语言包比较容易维护。 我个人不太建议全部写成非常短的 key，例如： title desc button message 因为项目一大，这些 key 很快就会失去语义。 十二、Chrome i18n 的语言选择机制 使用 chrome.i18n 后，不需要我们自己判断用户语言。 Chrome 会根据用户浏览器语言自动选择语言包。 比如项目里有： locales/en/messages.json locales/zh_CN/messages.json 如果用户浏览器语言是中文简体，Chrome 会优先使用： zh_CN 如果用户浏览器语言是英文，则使用： en 如果没有找到对应语言，会回退到 manifest 中配置的： "default_locale": "en" 所以在大多数情况下，我们不需要自己写： navigator.language 也不需要自己维护语言切换逻辑。 十三、Plasmo i18n 实现流程总结 整体流程可以总结为五步。 1. 创建语言包目录 locales/ ├── en/ │ └── messages.json └── zh_CN/ └── messages.json 2. 在 package.json 中配置默认语言 { "manifest": { "default_locale": "en" } } 3. 使用 __MSG_xxx__ 国际化扩展名称和描述 { "displayName": "__MSG_extName__", "description": "__MSG_extDescription__" } 4. 封装 i18n 工具函数 export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 5. 在 popup、content script、background 中统一调用 t("btn_confirm") t("batch_selectedCount", String(count)) t("content_newAccountDesc", platformName) 十四、这种方案的优点 我目前这个项目采用的是原生 chrome.i18n 方案，而不是引入 i18next 、 react-intl 之类的第三方库。 原因很简单：对于浏览器扩展来说，原生方案已经足够好用。 它的优点包括： 1. 不需要额外依赖 不需要安装额外 npm 包，减少 bundle 体积。 2. 和 Chrome 扩展天然集成 manifest 中的名称、描述都可以直接使用 __MSG_xxx__ 。 3. popup、content script、background 都能用 只要在扩展环境中，都可以调用： chrome.i18n.getMessage() 4. 构建简单 Plasmo 会处理扩展构建，不需要自己手动生成 _locales 。 5. 维护成本低 对于中小型浏览器扩展项目，这种方案非常轻量。 十五、需要注意的坑 1. 必须配置 default_locale 如果使用了语言包，但是 manifest 没有配置： "default_locale": "en" 扩展可能无法正确加载国际化资源。 2. key 必须在所有语言包中保持一致 比如英文有： "btn_confirm" 中文也应该有： "btn_confirm" 否则在某些语言下会取不到翻译。 3. messages.json 格式不能随便写 Chrome i18n 不是普通 JSON 字典，不能写成： { "btn_confirm": "Confirm" } 必须写成： { "btn_confirm": { "message": "Confirm" } } 4. 占位符要用 $1 、 $2 比如： { "conversation_total": { "message": "$COUNT$ conversations", "placeholders": { "count": { "content": "$1", "example": "10" } } } } 代码中： t("conversation_total", "10") 5. 不建议在代码里拼接多语言句子 不推荐： t("selected") + count + t("items") 推荐： t("batch_selectedCount", String(count)) 因为不同语言的语序可能不一样。 6. content script 中使用 innerHTML 时要注意安全 如果语言包内容完全由开发者自己维护，风险较小。但如果文案来自用户输入，就不要直接拼进 innerHTML 。 我的项目中的语言包是静态文件，由开发者维护，所以可以用于构造提示卡片。但如果要插入用户输入，最好使用 textContent 或做好转义。 十六、适合继续优化的方向 目前这个方案已经可以满足我的项目需求，不过后续还可以继续优化。 1. 给 key 增加 TypeScript 类型约束 现在的 t 函数是： export function t(key: string, substitutions?: string | string[]): string 也就是说 key 是普通字符串。 如果写错了： t("btn_confim") TypeScript 不会报错，只有运行时才会发现。 后续可以自动从 messages.json 生成类型，例如： type I18nKey = | "btn_confirm" | "btn_cancel" | "account_add" | "account_delete" 然后改成： export function t(key: I18nKey, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } 这样可以在开发阶段提前发现 key 拼写错误。 2. 编写脚本检查多语言 key 是否一致 可以写一个 Node.js 脚本，对比： locales/en/messages.json locales/zh_CN/messages.json 检查两个文件的 key 是否完全一致。 比如： en 中有但 zh_CN 中没有 zh_CN 中有但 en 中没有 这对项目变大后非常有用。 3. 拆分语言包 当 messages.json 变得非常大时，可以按模块维护源文件，例如： i18n-source/ ├── account.json ├── batch.json ├── tag.json ├── content.json └── error.json 然后通过脚本合并生成最终的： locales/en/messages.json locales/zh_CN/messages.json 不过对于大多数浏览器扩展项目，一个 messages.json 也完全够用。 十七、完整示例 下面给一个简化版完整示例。 package.json { "name": "multi-ai-conversation-manager", "displayName": "__MSG_extName__", "description": "__MSG_extDescription__", "manifest": { "default_locale": "en", "permissions": [ "storage", "alarms" ] } } locales/en/messages.json { "extName": { "message": "ChatGPT & Claude AI Conversation Manager" }, "extDescription": { "message": "Unified management for ChatGPT and Claude conversations" }, "btn_confirm": { "message": "Confirm" }, "btn_cancel": { "message": "Cancel" }, "batch_selectedCount": { "message": "$COUNT$ items selected", "placeholders": { "count": { "content": "$1", "example": "5" } } } } locales/zh_CN/messages.json { "extName": { "message": "ChatGPT、Claude AI 对话管理器" }, "extDescription": { "message": "统一管理 ChatGPT、Claude 平台的 AI 对话" }, "btn_confirm": { "message": "确认" }, "btn_cancel": { "message": "取消" }, "batch_selectedCount": { "message": "已选中 $COUNT$ 项", "placeholders": { "count": { "content": "$1", "example": "5" } } } } utils/i18n.ts export function t(key: string, substitutions?: string | string[]): string { return chrome.i18n.getMessage(key, substitutions) || key } popup.tsx import { t } from "./utils/i18n" export default function Popup() { const selectedCount = 5 return ( <div> <button>{t("btn_confirm")}</button> <button>{t("btn_cancel")}</button> <p>{t("batch_selectedCount", String(selectedCount))}</p> </div> ) } 结语 在 Plasmo 浏览器扩展项目中实现 i18n，并不一定要引入复杂的国际化框架。 对于大多数 Chrome 扩展来说，直接使用浏览器原生的 chrome.i18n API 就已经足够： manifest 文案使用 __MSG_xxx__ ； 页面和脚本中使用 chrome.i18n.getMessage() ； 封装一个简单的 t() 函数； 使用 locales/en/messages.json 、 locales/zh_CN/messages.json 管理语言包； 对变量文案使用 placeholders。 这种方式简单、轻量、和浏览器扩展生态天然兼容，非常适合 Plasmo 架构下的扩展开发。 我目前的项目就是采用这种方案，同时覆盖了 popup 页面、content script、background 消息处理和错误提示。整体使用下来，维护成本低，也方便后续继续增加更多语言支持。 1 个帖子 - 1 位参与者 阅读完整话题
最近在做 AI 辅助开发相关的实践，发现如果给工具补充清晰的项目上下文和规范（类似“项目记忆”），代码生成的质量和一致性会明显提升。 想调研一下大家现在的做法： 大家在项目里会专门维护类似下面这种 AI 协作规范文件吗？ AGENTS.md （Codex、Cursor 等工具可读取） CLAUDE.md （Claude Code 使用） 如果有维护的话，一般会写哪些内容？ 比如但不限于： 项目结构说明 技术栈约定 代码规范（lint / format / 命名等） Git 提交规范 测试要求 ADR / 架构决策记录 开发流程 / CI 流程 Todo / 任务流转规则 其他“给 AI 看的说明” 目前我们团队是开始尝试把这些内容逐步沉淀下来，感觉对 AI 理解项目上下文挺有帮助的。 想看看大家的实践情况： 现在是“各写各的”，还是已经有比较统一的最佳实践了？有什么踩坑经验也欢迎分享 11 个帖子 - 9 位参与者 阅读完整话题
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
本文完整内容见（包括 Agent 指令设计）： 原文地址 1 、Managed Agents 核心理念：解耦"大脑"与"双手" Managed Agents 定义：一套用于大规模构建、部署和运行 AI Agent 的全托管基础设施，核心设计原理围绕组件解耦与分层抽象，解决长周期 AI Agent 开发和生产部署的痛点。 Managed Agents 设计思路：将智能体的「决策能力」（模型作为"大脑"）、「执行能力」（工具/沙箱作为"双手"）和「记忆能力」（持久化会话作为记忆）完全分离； 借鉴操作系统分层思想重构 Agent 架构，各模块独立演进提升整体系统的稳定性。解决了传统 Agent 开发中 Agent 代码粘连、环境崩溃导致任务中断等问题。 Managed Agents 核心模块： Harness （可替换控制循环）：作为隔离模型实现与系统功能的抽象控制层，负责调度模型和路由工具，允许模型随时升级不影响系统稳定性，让针对特定模型的补丁可独立演进。 Sandbox （隔离执行环境）：提供独立的代码/文件执行单元，执行环境与核心系统物理隔离，避免工具调用异常或容器崩溃导致整体任务失败，将错误转化为可处理的单纯异常。 Session （持久化日志）：突破传统上下文窗口限制，将完整历史事件日志作为外部化记忆仓库，支持按需读取、回放历史和提取关键切片，解决长任务中信息存储与回溯的问题。 2 、Multica 介绍 Multica 是一个开源的 Managed Agents 平台，定位为遵循 Managed Agents 架构规范、厂商中立的开源 AI 智能体团队协作平台。 Multica 目标并非自建 Agent ，而是搭建跨 AI Agent 的托管调度层，将分散在本地、多终端、多厂商（ Claude Code 、Codex 、OpenCode ）的智能体收拢，把 AI Agent 转化为人机团队内和开发人员平权的正式成员，落地 Managed Agents 工程化、团队化实践。 Multica 核心为解决行业几类典型痛点： 多 AI 编程工具碎片化，切换繁琐、无法统一管控； Agent 孤立运行，无任务看板、无进度可视化，人工持续盯盘； Agent 单次优质执行经验无法沉淀，重复造轮子、团队能力无法复利增长。 3 、人机 Agent 团队组织设计 针对人机 Agent 团队协同，首先需要结合业务场景，进行团队组织设计，确定团队角色及职责。此处以 “ 全栈项目迭代开发 ” 为业务场景，落地实践人机多角色 Agent 团队协作。 针对研发需求交付流程，一般覆盖 「需求分析、方案设计、代码开发、代码审核、需求测试、项目部署」等环节。 其中“需求分析、方案设计、代码开发”类工作长耗时且低风险低，适合 Agent 角色执行；其他工作风险性相对高，短期（本文案例）持续让 人 来负责，未来考虑过度给 Agent 。 基于上述分工思路，团队具体组织设计如下： 团队名称 ：汉兴三杰（墨萧张联盟） 团队角色 ：由 3 个 Agent 角色（队长、架构师、全栈工程师） + 1 个 人 角色组成； 前者负责 「需求分析、方案设计、代码开发」类工作，后者负责「代码审核、需求测试、项目部署」类工作。 Agent 角色明细 ： 角色 职责定位责 权限边界 萧何（队长） 团队唯一对外交互入口，全流程总调度，承担「任务拆解、进度追踪、结果汇总」核心职能，是整个小队的定盘星 仅负责调度整合，不参与具体方案设计、不编写执行落地代码，所有具体工作全部委派给对应角色，绝不越界。 张良（架构师） 方案输出核心，承担「信息调研、复杂任务方案设计」核心职能，是连接需求与落地的核心枢纽 仅输出设计方案，不参与具体落地执行；遇到需求调整仅修改方案，不越界修改执行成果。 墨子（全栈工程师） 长周期任务执行核心，承担「长时间、独立复杂任务执行」核心职能，是将纸面方案转化为实际成果的攻坚者 仅在方案设计范围内完成执行，不自行修改整体框架、不扩展超出需求范围的额外功能；所有超出边界的需求统一返回协调者重新处理，不私自调整方案。 4 、场景案例 Multica 系统截图 ： Multica Squad：团队设置 + 成员组织（ 3xAgent + 1x 人）。 Multica Agent：Agent 角色的设置类信息。 墨子为例，设置信息包括：运行时（本地 MacMini + OpenCode ） + Agent 模型（ DeepSeek ） + 技能（ design-taste-frontend ） + 指令等。 Multica 运行时：我的电脑上安装了 Claude 、Codex 和 OpenCode ，如下图全部识别可用。 案例场景说明 ： 案例场景：“新建一个博客网站，只包含前端 HTML 页面，无需后端逻辑”。 需求承接：通过 Multica 的 Squad/团队 承接，过程中体现多智能体调度、会话隔离、事件追溯、技能等能力。 Multica 处理流程分析 ： Multica 流程参考下图，核心步骤如下： 发起任务 ：用户提交 ISSUE ，分配给 Multica 团队，此处分配给「汉兴三杰（墨萧张联盟）」。 需求分析/分配任务 ：团队接到需求，「萧何（队长）」会自动进行需求功能点提炼；然后，将方案设计设计任务分配给「张良（架构师）」。 技术方案 ：「张良（架构师）」接到任务，结合同步的需求信息、主动调研信息等，进行技术方案设计。技术方案完成后，会周知「萧何（队长）」。 方案评审 ：「萧何（队长）」接到技术方案完成通知，会进行技术方案 Review 。然后，将开发任务分配给「墨子（全栈工程师）」。 代码开发 ：「墨子（全栈工程师）」接到任务，开始进行代码开发。代码开发完成后，会周知「萧何（队长）」。 代码验收 ：「萧何（队长）」接到代码开发完成通知，会进行代码验收。验收完成后，会主动更新任务状态。 需求测试/项目部署 ：按照前文组织设计，这部分由人来处理。因此，由“Jason （我）”人工触发。 Multica 产出效果 ： 博客网站运行截图：
想用一下acwing的ac terminal，里面有yxc自己写的homework可以实践，感觉对学linux帮助应该挺大的。 4 个帖子 - 3 位参与者 阅读完整话题
最近用ai写代码，写完新建会话，让他审查，然后修改，继续新建会话，继续审查修改，结果他一直能审出大大小小的感觉挺有道理的问题，我要一直继续下去吗？ 1 个帖子 - 1 位参与者 阅读完整话题
最近在跑一些自动化渗透相关的skill，实践下来效果并不理想 JS文件获取少部分就进入下一步 对于懒加载JS文件是采用Chrome MCP让agent主动去点击页面的功能点加上注入脚本获取路由进行访问，这也是偷懒重灾区 接口提取不全 请教各位佬友们， 如何尽可能的做到让agent可以持续的深入，而非获取到一些结果后就跳出当前任务 大体流程如下 flowchart TD A[开始: 输入目标 target] --> B[Phase 0 Recon<br/>指纹 WAF 源码泄露 被动收集] B --> C[Phase 1 API Discovery<br/>JS落盘 深度分析 SPA路由 API签名提取] C --> D[Phase 2 Value Linkage<br/>全接口覆盖 响应挖掘 值池联动 无认证探测] D --> E[Phase 3 Crypto Attack<br/>JWT AES DES RSA 编码 签名分析] E --> F[Phase 3.5 Cross-Phase Feedback<br/>新Token ID Key回溯和前推] F --> G{是否满足高危探测条件} G -->|是| H[Phase 3.8 High Risk<br/>Swagger Actuator SQLi RCE SSRF SSTI Admin路径] G -->|否| J[跳过高危探测并记录 SKIPPED reason] H --> I{是否出现 401/403/405 或高价值阻断} J --> K[Phase 5 Exploit and Report] I -->|是| L[Phase 4 Bypass<br/>路径变形 方法切换 Header注入 OAuth CDN缓存] I -->|否| K L --> K K --> N[中文 .docx 报告<br/>PoC 证据链 修复建议 合规声明] 10 个帖子 - 4 位参与者 阅读完整话题
sub2api还是cpa？ 要不然的话，两个号要来回切换，也挺烦的 或者有什么更好的方法吗 5 个帖子 - 4 位参与者 阅读完整话题