#代码生成

宝玉
4周前
确实,Manus 很聪明,他们把工具分成了 3 层: 第 1 层:函数调用 (Function Calling) 这是最基础的一层,只保留一小组固定的、原子化的函数,比如:读写文件、执行 Shell 命令、搜索文件等。在 LLM 的系统提示词中就只有这一层的工具定义,相对比较少,15 个以内,输入格式和输出格式都很清晰,不容易出错,但这里面有两个工具很特殊,一个是 Shell, 一个是 File。 第 2 层:沙箱工具 (Sandbox Utilities) 每个 Manus 会话都运行在一个完整的虚拟机沙箱里。就是原推文提到的,虚机预装了很多命令行工具,比如格式转换器、语音识别工具,甚至一个 mcp 命令行客户端。 然后这些工具都通过第 1 层中定义的 Shell 来调用,就是命令行工具,命令行调用。 但是这么多工具模型怎么知道呢? Manus 在系统提示词里会直接告诉 LLM,在一个特定的文件夹里有很多预装的命令行工具。对于最常用的工具,直接列出它们的名字。不常用的,LLM 可以直接通过原推提到的命令列出所有命令行工具,通过 --help 参数来查看任何一个工具的用法,因为所有这些工具都是他们自己开发的,格式统一。 第 3 层:代码包与 API (Packages and APIs) 这一层其实就是 LLM 实时编写 Python 代码,通过代码实现更复杂的功能。比如用户想查询某个 API 的数据,可以直接用 Python 写一个函数,fetch API 的数据,并解析成需要的格式。 其实在 Codex 中,用 Python 代码当工具已经用的很多了。 由于复杂的运算都是代码完成的,返回给 主 Agent 的知识计算后的结果,所以并不会占用主 Agent 的上下文。 这样 3 层设计的好处是,从模型的角度看,它需要调用的工具就固定是第 1 层的十几个,而借助命令行和代码,它又可以衍生出无数的工具组合。 还有一点就是我在之前推文提到的子智能体,Manus 也是大量采用“智能体即工具 (agent as tool)”的模式。把子智能体当工具用,比如负责检索是一个子智能体,但是这个子智能体在主 Agent 看来就是一个工具。同时也可以很好的起到减少上下文的效果。
meng shao
1个月前
[开源推荐] Amplifier:微软官方开源,Claude Code 等 AI 编程智能体的超级倍增器!它通过整合已验证的开发模式、专业化智能体和自动化工作流,帮助开发者更快地构建复杂解决方案,避免从零开始重复试验。 核心目标与价值 Amplifier 的愿景是实现“描述即构建”的未来:用户用自然语言描述需求,AI 即可生成并测试多个方案,同时积累知识以提升长期效率。它强调工具中立性,设计为可移植框架,能适应各种 AI 技术演进。目前作为研究演示器,它不保证稳定性,但展示了 AI 辅助开发的潜力,尤其适合处理架构设计、调试、安全审查等复杂场景。 关键特性 · 20+ 专业智能体:针对特定任务的专家,如 zen-architect(简约架构设计)、bug-hunter(系统性调试)、security-guardian(安全分析)和 performance-optimizer(性能优化)。这些智能体可通过自然语言命令调用,例如“用 zen-architect 设计缓存层”。 · 并行工作树系统:使用 Git worktree 隔离多个实验分支,同时测试 10 种方案,避免主分支混乱。 · 知识提取系统:自动从文档中抽取概念、关系和模式,形成可查询知识库,支持命令如 make knowledge-query Q="认证模式",并生成可视化图谱。 · 对话记录管理:在 Claude Code 压缩上下文前自动导出完整历史,支持搜索和恢复,防止关键细节丢失。 · 模块化构建器:一键工作流,从合约/规范到生成/审查,支持自动、辅助或干跑模式,适用于快速原型开发。 · 自动化工具:内置质量检查、代码格式化和测试命令,提升开发卫生。 如何工作 Amplifier 在 Claude Code 基础上扩展:克隆仓库后运行 make install 安装依赖,激活虚拟环境,然后启动 claude 即可加载所有增强。用户可在 Amplifier 目录或外部项目中使用智能体和工具;知识更新通过 make knowledge-update 处理文档;并行开发用 make worktree feature-name 创建分支。整个系统注重分解策略、演示驱动开发和元认知配方,确保 AI 输出高效且可控。 目标用户与适用场景 主要面向使用 AI 助手的软件开发者,特别是那些处理多任务、知识密集型项目的团队。它在 Windows WSL2 上测试最充分,也支持 macOS 和 Linux。适合架构师、调试专家或知识管理需求高的角色,但不推荐生产环境使用。 技术栈与安装 · 核心技术:Python 虚拟环境、Claude Code、Git、Makefile 和 Shell 脚本。依赖 Claude Code 环境处理智能体和记录。 · 使用示例:启动 Claude 后,输入 /modular-build 构建模块,或 /transcripts 管理记录。
sitin
1个月前
大家都知道,VSCode 本身的插件生态已经很强大了,排在最受欢迎榜单前五十的,基本都是写代码必备,比如 Pylance、Jupyter、Docker、Prettier、Copilot、WSL 这些。装上之后,写代码体验会提升一个档次。 不过最近更有意思的是 —— AI 编程插件越来越多,而且真的很好玩。以前写代码可能有点枯燥,现在你可能一句话就能生成一堆代码,甚至直接“对话式开发”。今天整理了 几个目前最受欢迎的 VSCode AI 插件,值得收藏。 1.Continue 完全开源的 AI 编程插件,免费用。 它就像是 Copilot 的“平替+进阶版”,支持 AI 对话写代码、自动补全、智能修改,还能通过快捷键随时唤起。 最大的亮点是:能接入十几种大模型,比如 OpenAI、Claude、DeepSeek 等。 2.Cline 一句话总结:免费 + 简单 + 强大。 只要绑定 ChatGPT、Claude 等 API,就能对话式编程。想象一下,你随便聊几句,VSCode 就能帮你搞出一个软件雏形。 3.GitHub Copilot / Copilot Chat AI 编程鼻祖,微软+GitHub 官方出品 代码自动补全、根据注释生成代码、解释代码、Chat 模式交互,任何层次开发者(尤其是主力用 GitHub 的人) 4.CodeGPT 这是一个商业插件,界面更干净,功能排布清晰。 用过 Cursor 的人会觉得很熟悉,主打的就是代码生成和补全,偏向“简洁实用派”。 5. AI Toolkit 这是一个更专业的工具箱,专门面向大模型的调试和测试。 你不仅可以直接调用 75个在线模型,还可以连接本地模型,甚至进行微调 (Fine-tuning)。 对喜欢折腾模型的开发者来说,这个插件相当于一站式 Playground。 6.Graphite (AI Code Review) 智能代码审查助手,AI 帮你做 PR 审查、优化建议,需要频繁提交和审查 PR 的团队 VSCode + AI 插件,已经让“写代码”这件事变得完全不一样了: 新手可以降低门槛,快速跑起来; 老手能提升效率,把时间花在更有价值的地方; 甚至还有可能一句话写一个应用。
sitin
1个月前
说句实在的,写程序最费时间的,往往不是“想清楚怎么做”,而是那些重复又机械的活: 接口要搭脚手架、参数一变要改一堆文件、修个 bug 还得补测试。活不难,就是耗时。 在众多工具中,Codex 和 Claude Code 是讨论度最高的两个,一个专注于把自然语言快速翻译成代码,另一个则成为项目里的智能合作者,这两个工具的功能定位不相同,开发者可以根据自己的需求来选择最合适的助手。 Codex:把“人话→代码”的速写笔,写小功能、补逻辑超快。 Claude Code:项目里的AI 同事,能读仓库、跨文件改、还会配合 Git 整套流程。 各自最好用的场景 Codex:脚本/小工具/原型验证,几句话就能吐出可运行代码。 我常见的用法: 写个 API、补个校验、加个小逻辑,几秒出底稿; 在 IDE 里自动补全,敲起来很顺; 场景适配广,Python/JS 这类主力语言表现都不错。 一个直观例子:要做“注册接口(Flask)”,又要校验、又要错误处理——自己从零写嫌烦?直接丢给 Codex。一分钟不到,给你一个能跑的雏形,然后你再按需求微调。 什么时候用 Codex 最舒服——小功能/小脚本、学习练习/验证想法、写模板化代码、重复性强的环节 Claude Code:搭脚手架、批量改接口、同步更新测试 & README、开分支提 PR。 它会读你的项目上下文,理解模块之间的关系,然后跨文件动手改,并且直接融入 Git 工作流(commit/分支/PR 一条龙)。 常见的它能干的事: 一句话需求,它直接搭项目结构、写核心逻辑、再补测试; 接口参数改了,同时更新调用方和测试; 和 Git 打通,一边改一边提交,像真的有同事在配合你。 举个例子: “来一个命令行任务管理工具(Python + click)——要项目骨架(src/tests/README/setup.py),还要可用的 task_manager.py,再顺手写点单测。” Claude Code 通常几分钟就把骨架/逻辑/测试铺好,你直接 pip install -e . 跑起来看效果,再微调就行。 什么时候用 Claude Code 最称手——要跨文件改动的需求;需要测试/文档/项目结构一套齐;团队协作、要走 Git 流程的活 怎么选(直给) 个人、脚本党、追速度 → 选 Codex。 团队、跨文件改动、要交付 → 选 Claude Code。 最佳实践:局部用 Codex,整体让 Claude Code 收尾。 我自己踩过的坑 & 使用感受 刚上手 Claude Code 时,一定要把需求拆清楚,比如“要哪些目录/文件、基本命令、最小可用功能、要不要测试”。它就像懂事的实习生,你说清楚,它干得漂亮。 Codex 给出来的底稿,别无脑照抄。生成很快,但边界条件、异常、幂等这些,最好自己再走一遍。 跨文件大改时,不要一次丢 30 条需求,分批走,每一步让它 commit 一次,出现问题好回滚。 最后一句:工具的体验,和使用场景、你的工作习惯强相关。 分享一点使用的个人感受哈,虽然感觉大家普遍说codex很慢,不过因人而异。 工具嘛,自己用的顺手最重要,每个团队/人需求不一样,找到最顺手的组合,才是生产力的最大化。
数码荔枝
2个月前
看到关于 vibe coding 的讨论,我想分享自己的经历: 作为一个稍微有点聪明但不多、半吊子 PM、大学连 C++ 指针都没学明白的代码苦手,如果不是 ChatGPT 的诞生,我应该是永远写不出目前在用的一些效率小脚本了。 即便如此,当我试图用“自认为严谨”的方式描述新功能需求,并交给 AI 生成代码时,结果往往不尽如人意:要么直接报错,或者实现效果 vs 预期相差甚远。接下来,我只能一遍一遍把报错信息 or 差异丢给 AI,企图让它自己不断尝试改进代码。 所以,我觉得如果有人认为借助AI就能轻松变成“程序员”,那只有一种可能:他对AI交付的代码没有任何细节上的要求。比如,让 AI 生成一个 Landing Page 确实没问题,因为只要页面看起来像模像样,顺便填充了 AI 味十足的文案,就算是心满意足了。 但如果希望 AI 在生成代码时关注某些细节,或者实现特定框架下的功能,那就很难了—— 因为不懂代码、不懂框架,所以没法在正确方向提出要求,只能被迫接受一个“看起来还行”的结果。 然而,更多时候,自己都没有意识到“还需要关注某些细节”,因为也不知道究竟有哪些细节需要关注… 总之,虽然 AI 对我帮助很大,但我也清晰意识到:我这种靠 AI 点亮编程技能的人, 无论是执行力还是效率,和“靠写代码吃饭”的人没法比。 保持谦卑,保持尊重。