上海实习生招聘，基础软件/嵌入式软件方向，有意留下联系方式沟通 要求： 1. 27 年毕业，会有编程考试 2. 有学校的要求，可以细聊 3. 实习工资挺好的 4. 要求实习 2 个月
如题 目前主要在搞ai、编程、ai画画这类东西，比较想知道这方面有没有什么羊毛 或者还有没有什么生活或者旅游方面的福利 3 个帖子 - 3 位参与者 阅读完整话题
自从有了AI，开始vibe coding，感觉越来越懒了，一些简单的代码都懒得写，能用AI就不动手。都快感觉之前的编程能力有退化迹象 各位佬，现在还回得去没有AI的编程日子吗 22 个帖子 - 18 位参与者 阅读完整话题
mac 上豆包输入法的语音输入很好用，win 上的微信输入法也更新了语音输入功能，目前耳机的麦克风收音不好，口喷编程的时候经常把对面同事的声音也录进去了，大家有没有好的麦克风推荐？动圈麦克风？电容麦克风？对这个领域不太熟悉。
mac 上豆包输入法的语音输入很好用，win 上的微信输入法也更新了语音输入功能，目前耳机的麦克风收音不好，口喷编程的时候经常把对面同事的声音也录进去了，大家有没有好的麦克风推荐？动圈麦克风？电容麦克风？对这个领域不太熟悉。
mac 上豆包输入法的语音输入很好用，win 上的微信输入法也更新了语音输入功能，目前耳机的麦克风收音不好，口喷编程的时候经常把对面同事的声音也录进去了，大家有没有好的麦克风推荐？动圈麦克风？电容麦克风？对这个领域不太熟悉。
mac 上豆包输入法的语音输入很好用，win 上的微信输入法也更新了语音输入功能，目前耳机的麦克风收音不好，口喷编程的时候经常把对面同事的声音也录进去了，大家有没有好的麦克风推荐？动圈麦克风？电容麦克风？对这个领域不太熟悉。
大家有什么好的移动端实时人像分割方案吗。 看过 PaddleSeg ，和 mediapipe ，在低端手机上性能还是不够。
菜B新人一枚，资深互联网人士，0编程经验，终于不用靠谷歌搜索话题了 4 个帖子 - 3 位参与者 阅读完整话题
很多人第一次接触 AI 编程助手时，都会把它当成“高级搜索引擎”或者“代码生成器”。但真正用下来之后我发现，Codex 最有价值的地方，并不是帮你凭空写一段代码，而是帮你在复杂项目里更快理解上下文、更稳地定位问题、更安全地完成修改。 这篇文章不讲具体项目业务，只分享我在维护项目过程中总结出来的一些实战经验。对刚开始使用 Codex 的同学来说，这些方法能少走很多弯路。 一、先让 Codex 读规则，而不是马上写代码 刚开始用 Codex 时，我很容易犯一个错误：问题一抛过去，就希望它马上给方案、改代码、跑测试。 后来发现，真正高效的方式是先告诉它项目规则。 比如： 项目有哪些子模块 每个模块用什么技术栈 构建命令是什么 哪些目录能改，哪些不能乱动 当前项目有哪些约定 测试、构建、发布分别怎么跑 有哪些历史遗留问题需要避开 这类信息最好写成类似 AGENTS.md 的说明文件。这样 Codex 进入项目后，第一件事不是“猜”，而是“按项目手册工作”。 我的经验是： 越复杂的项目，越不能让 AI 靠猜。你给它越清晰的操作边界，它越像一个靠谱的协作者。 二、让 Codex 先理解现状，再动手修改 很多时候，我们觉得自己只是要改一个小问题，但真实项目里，一个小改动可能牵连配置、接口、构建脚本、前端页面、后端服务、移动端兼容等多个地方。 所以我现在会习惯性要求 Codex： 先查相关代码 找调用链 看现有实现风格 判断影响范围 再决定怎么改 尤其是在维护老项目时，这一点非常重要。 不要直接说： 帮我把这个功能改成 xxx。 更好的说法是： 先帮我看看这个功能现在是怎么实现的，涉及哪些文件和调用链，然后再给出修改方案。 这样 Codex 不会一上来就“自信开写”，而是会先进入侦察模式。等它把上下文摸清楚之后，再进入修改模式，成功率会高很多。 三、善用 CodeGraph，别让 Codex 大海捞针 维护大型项目时，单纯全文搜索经常不够用。一个类、一个函数、一个接口，可能散落在很多模块里。 这时候 CodeGraph 这种代码索引工具非常有用。它能帮 Codex 快速知道： 某个方法在哪里定义 谁调用了它 它又调用了谁 改它会影响哪些地方 某个功能大概分布在哪些文件中 我的体感是，CodeGraph 相当于给 Codex 装了一张“项目地图”。 没有地图时，它需要在代码森林里乱翻。 有地图后，它可以直接走到关键区域。 所以维护项目时，我会优先让 Codex 用代码图谱定位，再做具体阅读和修改。这样不仅快，而且不容易漏掉关键调用点。 四、把构建命令固定下来，别每次临时发挥 项目一复杂，环境问题就会变成噩梦。 比如： 后端需要某个 Java 版本 另一个服务需要另一个 Java 版本 前端要固定 Node 版本 Android、iOS、脚本服务又各有自己的工具链 有些模块用 Maven，有些用 Gradle，有些用 npm/yarn 如果每次都让 Codex 自己猜命令，很容易出现“代码没问题，环境跑崩”的情况。 我的做法是把常用命令整理成脚本： build-backend.sh build-web.sh build-android.sh build-ios.sh check-all.sh status-all.sh 然后告诉 Codex： 不要自己拼命令，优先使用项目提供的脚本。 这点非常关键。 因为脚本里可以固定 JDK、Node、Maven、SDK、环境变量、registry 等细节。Codex 只需要执行标准入口，不需要重新理解整个环境。 结论就是一句话： 把复杂环境封装成脚本，把脚本交给 Codex 调用。 五、每次改代码前，先看工作区状态 多人协作或者长时间维护项目时，工作区里可能已经有别人改过的文件，或者有自己之前没提交的临时改动。 如果不先看状态，Codex 可能误改、覆盖、格式化不该动的文件。 所以我会让 Codex 在动手前先跑状态检查，确认： 当前有哪些文件被修改 哪些改动可能是我已有的 这次任务真正应该碰哪些文件 有没有需要避开的脏文件 这其实是一个非常工程化的习惯。 AI 写代码的能力很强，但它不知道哪些改动是“历史现场”。 你必须让它尊重现场。 我现在的原则是： 只改和任务相关的文件，不顺手重构，不清理无关改动，不替用户做危险操作。 这能避免很多不必要的事故。 六、把 Codex 当初级同事用，会翻车；当资深搭档用，才好用 很多人用 AI 的方式是命令式的： 写一个 xxx。 修一下 xxx。 加一个 xxx。 这种方式适合小脚本，但不适合真实项目。 在真实维护工作中，我更推荐把 Codex 当成一个资深搭档，而不是一个代码打字员。 你可以这样用它： “先帮我分析这个问题可能出现在哪一层。” “这个改法会不会影响已有逻辑？” “有没有更贴合当前代码风格的实现方式？” “帮我找一下类似功能是怎么写的。” “这个地方有没有隐藏的兼容性风险？” “改完之后应该跑哪些最小验证？” 你会发现，当问题问得更工程化，Codex 的回答也会更工程化。 AI 不是只能写代码，它还可以帮你做： 代码考古 风险评估 调用链分析 方案对比 测试补充 构建验证 文档整理 真正的效率提升，来自这些环节串起来。 七、不要追求“一次生成完美代码” 我现在越来越不指望 Codex 一次性生成完美答案。 更高效的节奏是： 让它先定位问题 让它提出最小修改方案 修改后跑测试或构建 根据错误继续收敛 最后总结改动和风险 这和真实开发流程很像。 AI 辅助开发不是“许愿机模式”，而是“快速迭代模式”。 尤其是复杂项目，第一次方案可能只对了一半，这很正常。关键是 Codex 能根据编译错误、测试失败、日志输出继续修正。它不会累，也不会嫌麻烦，这一点非常适合处理维护类工作。 八、让 Codex 跑验证，而不是只相信代码看起来对 只改代码不验证，是非常危险的。 我会尽量让 Codex 在修改后做对应检查： 后端改动跑后端构建 前端改动跑前端构建 移动端改动跑对应编译 脚本改动跑语法检查或单元测试 公共逻辑改动尽量跑更大范围验证 如果构建太重，也至少跑最相关的局部检查。 这一步的价值很高。因为 Codex 不只是“写完了”，而是可以帮你把“能不能过”这件事也确认掉。 我最喜欢的一种用法是： 改完后帮我运行最小必要验证，如果失败，继续根据错误修。 这样整个闭环就完整了。 九、明确告诉 Codex：不要过度发挥 AI 很容易“顺手优化”。 比如你只是让它修一个 bug，它可能顺便： 改了格式 重构了结构 换了写法 调整了命名 改了无关文件 加了不必要的抽象 这些在新项目里可能无所谓，但在维护项目时很危险。 所以我会明确给它约束： 保持改动最小 遵循现有风格 不做无关重构 不碰无关文件 不覆盖已有改动 不引入新的依赖，除非确实必要 修改公共逻辑前先分析影响范围 维护项目最怕“看起来更优雅，实际上风险更大”。 Codex 很强，但你要给它刹车系统。 十、让 Codex 最后交付一份清晰总结 一次好的 AI 协作，不应该只留下代码改动，还应该留下清楚的交代。 我通常希望 Codex 最后说明： 改了哪些文件 解决了什么问题 核心逻辑怎么变了 跑了哪些验证 有没有未验证的风险 后续还可以做什么 这份总结对自己回顾、写 commit message、发 PR、同步团队都很有帮助。 尤其是当你一天内处理很多小问题时，Codex 的总结能帮你快速恢复上下文。 我的 Codex 使用心法 总结下来，我觉得 Codex 辅助维护项目的核心不是“让 AI 多写代码”，而是“让 AI 更好地参与工程流程”。 我的使用心法大概是这几条： 先给规则，再给任务。 先理解上下文，再修改代码。 优先使用项目已有脚本和工具。 改动越小越好，验证越明确越好。 尊重已有工作区，不覆盖别人的现场。 把 Codex 当协作者，而不是代码生成器。 复杂问题分阶段推进，不追求一步到位。 每次交付都要有总结、有验证、有风险说明。 结语 小白使用 Codex，最开始可能会觉得它只是“帮我写代码的工具”。 但真正用进项目维护流程之后，你会发现它更像一个随时在线的工程搭档：能帮你读代码、查调用链、分析风险、执行构建、修复错误、整理结论。 它不能替代你的判断，但能显著放大你的判断。 它不能保证每次都对，但能让你更快接近正确答案。 所谓“小白成神”，并不是因为 AI 让人突然无所不能，而是因为它把很多原本需要大量经验积累的工程动作，变成了可以被学习、复用和自动化的流程。 会提问、会约束、会验证、会迭代。 这才是用好 Codex 的真正干货。 3 个帖子 - 2 位参与者 阅读完整话题
如图所示，我的是试用账号只有Opus 4.8可用，如果是付费用户可以使用 Fable 5 Fable 5启用方式可参考： https://linux.do/t/topic/2357711 Notion business 上线 fable 5, 附 启用方法 前沿快讯 [image] 在 notion AI 启用即可。 该模型必须要求启用数据保留。 默认情况下，Notion AI为企业版工作区使用零数据保留的LLM提供商，非企业版工作区的数据保留不超过30天，因此除非您主动启用，数据保留型LLM在您的Notion工作区中将处于关闭状态。 Coding Tool MCP 项目地址： Client Challenge 1 个帖子 - 1 位参与者 阅读完整话题
小米今天发布并开源了自己的AI编程助手Mimo Code，作为一个米粉，肯定要试试。Mimo Code内置持久记忆系统，用项目记忆、会话检查点、任务进度三重机制，解决AI健忘。内置专属的Harness系统，让模型的能力与框架深度配合。还有独创的Compose模式，给一个简单的想法就能自动完成设计、规划、编码、测试、审查，并最终交付一套工业级的成品。 我用Mimo Code,搭配deepseek V4pro，开发了一个贪吃蛇，效果还可以，但是花费的时间确实长，总共耗时40分钟。有佬友用了么，过来交流交流经验 3 个帖子 - 2 位参与者 阅读完整话题
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？
vibe 这俚语用来形容这个新事物其实很贴切，vibe coding 就是讲究一个感觉，颇有感觉来了一切皆可抛的意味。vibe 本身也是俚语，比较随和。 但是“氛围”这个中文词就显得太拘谨、太书面了。 英文日常语境中你可以说一个人 vibing 、一件事有 good vibe ，但在中文语境中提到“氛围”，大家只觉得你在对音乐或者灯光布景发表高见。 我就顺着想到底应该怎样翻译这个词呢，首先应该突出一个随意、突出一个不在乎，所以： 随性编程 随心编程 甚至 随意编程 随便编程 如果考虑一下中文流行语，或许也可以： 松弛编程 内味儿编程 在下抛砖引玉了，v 友怎么看？