#版本控制

avatar
宝玉
2周前
YC 编写的 《Vibe Coding 指南》 与 AI 结对编程，就像是拥有了一位虽然才华横溢、但偶尔会“走神”的实习生。它能在一小时内帮你完成过去需要一周才能搞定的工作，但有时也会在你项目的核心代码里悄悄埋下一个“惊喜”。 那么，如何才能驾驭好这位强大的编程伙伴呢？我们采访了多位利用 AI 编码的创始人，总结出了这套实用的“AI 协作编程指南”。 规划流程 好的开始是成功的一半。别指望“凭感觉编程” (Vibe Coding) 能带你走向成功。与 AI 高效协作的第一步，是制定一个清晰的路线图。 • 制定周详计划: 首先，和你的 AI 助手一起，在 Markdown 文件里写一份详尽的实施计划。 • 评审与精简: 审视这份计划，删掉不必要的部分。如果某个功能过于复杂，果断地将其标记为“暂不开发”。 • 控制项目范围: 单独开辟一个“未来想法”区域，把暂时不做的好点子都放进去，这能帮助你保持专注。 • 小步快跑，增量实现: 按部就班，一部分一部分地去实现，不要试图一口气吃成个胖子。 • 追踪进度: 每当一个部分成功实现后，让 AI 将其标记为“已完成”。 • 频繁提交: 在进入下一个环节之前，确保每个能正常工作的部分都已提交到 Git。 版本控制策略 当你的 AI 伙伴开始“自由发挥”时，版本控制系统就是你最可靠的后悔药。 • 将 Git 奉为圭臬: 不要完全依赖 AI 工具自带的撤销功能，Git 才是你的生命线。 • 从干净的起点开始: 每开发一个新功能，都确保你的 Git 工作区是干净的。 • 果断重置: 如果 AI 开始“天马行空”，让代码变得一团糟，别犹豫，立即使用 git reset --hard HEAD 命令回到上一个正常的状态。 • 避免问题滚雪球: 一次又一次失败的尝试，只会在错误的代码上堆砌更多错误的代码。 • 清爽地实现: 当你最终找到解决方案后，先重置代码库，然后在一个干净的版本上重新、清爽地实现它。 测试框架 和 AI 协作时，测试不仅是保证质量的手段，更是防止它“好心办坏事”的护栏。 • 优先进行高层级测试: 相比单元测试，优先编写端到端的集成测试。 • 模拟用户行为: 通过模拟真实用户在网站或应用中的点击操作来测试功能。 • 捕获“回归”问题: 大语言模型 (LLM) 常常会在修改代码时，无意中破坏一些不相关的功能。测试能帮你及时发现这些问题。 • 先测试，再前进: 在开始下一个新功能之前，确保所有现有的测试都能通过。 • 用测试作为护栏: 一些创始人建议，可以先编写测试用例，这能为 AI 的工作提供清晰的边界和目标。 高效修复 Bug 当 Bug 出现时，别单打独斗，让 AI 帮你分析。 • 善用错误信息: 很多时候，你只需要把完整的错误信息直接复制粘贴给 AI，它就能给出解决方案。 • 先分析，再动手: 在急于写代码修复之前，先让 AI 分析并列出几种可能导致 Bug 的原因。 • 失败后就重置: 每次修复尝试失败后，都回到干净的代码状态再进行下一次尝试。 • 添加日志: 在关键位置添加日志记录，能帮你和 AI 更好地理解代码的实际运行情况。 • 切换模型: 如果一个 AI 模型卡住了，不妨换个别的模型试试，也许会有意想不到的效果。 • 清爽地修复: 和开发新功能一样，一旦找到 Bug 的根源，就重置代码，然后干净利落地实现修复方案。 AI 工具优化 工欲善其事，必先利其器。充分配置你的 AI 工具，能让协作效率更上一层楼。 • 创建指令文件: 在项目里创建专门的指令文件（比如 cursor.rules, windsurf.rules, ），把详细的指令和规范写在里面。 • 本地文档: 把需要用到的 API 文档下载到项目文件夹里，这能让 AI 的回答更加准确。 • 多工具协作: 有些创始人甚至会在同一个项目上同时运行 Cursor 和 Windsurf 这样的不同工具。 • 各取所长: 通常，Cursor 在处理前端任务时速度更快，而 Windsurf 更擅长处理耗时较长的复杂任务。 • 货比三家: 让不同的工具生成多种解决方案，然后挑选出最好的那一个。 复杂功能开发 面对复杂的大型功能，关键在于“化整为零”。 • 创建独立原型: 先在一个全新的、干净的代码库里，把复杂功能的核心部分构建成一个独立的原型。 • 提供参考范例: 指向一个已经能正常工作的代码示例，让 AI 学习和模仿。 • 明确边界: 保持外部 API 的一致性，允许 AI 在内部自由修改和重构。 • 模块化架构: 基于服务的模块化架构，由于其边界清晰，比庞大的单体仓库 (monorepo) 更适合与 AI 协作。 技术栈的选择 你的技术选择，会直接影响 AI 的发挥。 • 成熟框架表现更佳: 像 Ruby on Rails 这样拥有 20 年发展历史和大量惯例的框架，AI 对其理解更深。 • 训练数据是关键: 像 Rust、Elixir 这样的新兴语言，由于可供 AI 学习的公开代码较少，AI 的表现可能会稍逊一筹。 • 模块化是王道: 把代码拆分成更小的文件，不仅方便人类阅读，也更容易让 AI 理解和处理。 • 避免“万行神文件”: 不要让单个文件膨胀到数千行，这会成为你和 AI 的噩梦。 编码之外的妙用 AI 的能力远不止写代码。 • DevOps 自动化: 让 AI 帮你配置服务器、DNS 和托管服务。 • 设计辅助: 用 AI 生成网站图标 (favicon) 和其他设计元素。 • 内容创作: 帮你起草产品文档和市场营销文案。 • 你的私人教师: 让 AI 逐行解释它生成的代码，帮助你学习和理解。 • 利用截图: 遇到界面 Bug 或想借鉴某个设计时，直接把截图发给 AI。 • 语音输入: 借助像 Aqua 这样的工具，你可以用每分钟 140 个单词的速度通过语音输入指令，比打字快得多。 持续改进 与 AI 的合作是一个不断磨合、共同进步的过程。 • 定期重构: 当你建立起完善的测试体系后，就可以大胆地、频繁地进行代码重构。 • 发现改进机会: 主动询问 AI，让它帮你找出代码中可以重构优化的部分。 • 紧跟潮流: 每个新模型发布后都去试试，了解最新的技术进展。 • 认识模型特长: 不同的模型有不同的“性格”和擅长的领域，学会在合适的任务中选择合适的模型。
AI编程工具激战：Claude Code、Gemini Cli崛起· 901 条信息
#AI 辅助编程 #Vibe Coding 指南 #版本控制 #测试框架 #持续改进
avatar
ginobefun
1个月前
刚在 Hacker News 上看到一篇关于 API 设计的文章，觉得写得特别实在，很有共鸣，想跟大家分享一下里面的几个关键点，看看对我们现在做的事情有没有启发。 作者的核心思想很简单：一个好的 API，首先是无聊的。 什么叫无聊？就是说它应该非常符合直觉，让调用它的开发者不需要看太多文档，凭着经验就能猜到怎么用。任何需要让开发者花时间去琢磨的聪明或有趣的设计，其实都增加了他们的使用成本。 在这之上，API 的设计总是在两个目标之间找平衡：一是刚才说的易用性，二是为未来考虑的灵活性。因为 API 一旦发布，就很难再改了。 文章里有几个观点，我觉得特别值得我们思考： 第一，也是最重要的一条原则：绝对不要破坏用户的应用。 作者把这称为 API 维护者的神圣职责。一旦我们发布了 API，别人就会依赖它来构建自己的业务。任何破坏性的变更，比如删掉一个字段或者改变它的结构，都会立刻搞垮下游的应用。这不仅仅是技术问题，更是信任问题。 文章里举了 HTTP 协议里那个著名的例子：Referer 这个头，其实是单词 Referrer 的拼写错误。但几十年了，也没人去修正它，因为改动它的代价太大了。这种对稳定性的尊重，是很值得我们学习的。 第二，关于变更和版本控制。 既然不能轻易做破坏性变更，那产品需要迭代时怎么办？答案是版本控制，比如在 URL 里加上 /v1/, /v2/。 但作者也强调，版本控制是必要的恶，是万不得已的最后手段。因为每增加一个版本，我们的维护成本就会翻倍，需要测试、支持和维护的东西越来越多。对用户来说，不同版本的文档也会让他们感到困惑。所以，我们在设计初期就要想得长远一些，尽量避免以后需要用版本控制来收拾烂摊子。 第三，API 的成功最终取决于产品。 这一点我觉得特别真实。API 只是一个工具，一个访问我们服务的窗口。如果我们的产品本身价值够大，就算 API 设计得再烂（作者点名了 Jira 和 Facebook），大家还是会捏着鼻子用。反过来，如果产品本身没人需要，那 API 设计得再优雅也没用。 这对我们的启发是，一个设计混乱的产品，几乎不可能有一个清晰好用的 API。因为 API 只是内部业务逻辑的一层映射。所以，想让 API 变好，首先得把内部的产品模型和逻辑理清楚。 最后，是一些非常具体的实战建议： - 认证要简单：除了支持 OAuth 这种复杂的流程，一定要提供一个简单的 API Key。很多用户可能不是专业的后端工程师，他们只想写个小脚本快速验证一下想法。简单的 API Key 能极大地降低他们的入门门槛。 - 写操作要支持幂等：网络请求总会遇到超时或者失败。用户重试请求时，怎么保证一个操作不会被执行两次？比如重复创建订单。方法就是支持幂等键，让调用方在请求里带上一个唯一的 key，我们后台根据这个 key 来识别和忽略重复的请求。 - 必须有速率限制：用户是通过代码来调用 API 的，一个死循环就可能在瞬间打垮我们的服务。所以，一定要有速率限制来保护系统。同时，最好在响应头里告诉用户他们还剩多少配额，这样他们的程序也能更智能地控制请求频率。 - 分页要用游标：当返回一个很长的列表时，比如几万条记录，用传统的 page=2 这种方式性能会很差，因为数据库在查询时需要数过所有前面的记录。更好的方法是基于游标的分页，客户端的请求会变成“给我 ID 大于 X 的后 20 条记录”，这对数据库来说效率非常高。 总的来说，这篇文章给我的感觉就是非常务实，不谈那些花哨的理论，而是专注于如何构建一个稳定、可信赖、对开发者友好的 API。核心就是：尊重你的用户，把稳定性当做最高优先级，并努力降低他们的使用成本。 大家可以想想，在我们自己的项目里，哪些地方可以借鉴这些经验。分享完了，大家有什么想法吗？
#API设计 #易用性 #稳定性 #版本控制 #速率限制
avatar
黄赟
1个月前
我的提示词，一般随 SideProject 一起保存，除了 Readme(MD), 还会有 Promots (MD). 拿台老机器装 Gitblit, 提示词随 Code 一起做 Git 版本控制 不知道大家有没有更另类的玩法？
#sideproject #Gitblit #提示词管理 #版本控制 #技术分享
avatar
BadUncle
3个月前
来自reddit用户分享的claude code 16条使用建议 ---比如：verbose，Opus优先，github cli代替fetch，分开维护git 1. 维护 CLAUDE[.]md 文件 建议为不同子目录（如测试、前端、后端）分别维护 CLAUDE[.]md，记录指令和上下文，便于 Claude 理解项目背景。 2. 善用内置命令 ▫ Plan mode（shift+tab）：提升任务完成度和可靠性。 ▫ Verbose mode（CTRL+R）：查看 Claude 当前的全部上下文。 ▫ Bash mode（!前缀）：运行命令并将输出作为上下文。 ▫ Escape 键：中断或回溯对话历史。 3. 并行运行多个实例 前后端可分别用不同实例开发，提高效率，但复杂项目建议只用一个实例以减少环境配置麻烦。 4. 使用子代理（subagents） 让多个子代理从不同角度解决问题，主代理负责整合和比较结果。 5. 利用视觉输入 支持拖拽截图，Claude Code 能理解视觉信息，适合调试 UI 或复现设计。 6. 优先选择 Claude 4 Opus 高级订阅用户建议优先用 Opus，体验和能力更强。 7. 自定义项目专属 slash 命令 在 `.claude/commands` 目录下编写常用任务、项目初始化、迁移等命令，提升自动化和复用性。 8. 使用 Extended Thinking 输入 `think`、`think harder` 或 `ultrathink`，让 Claude 分配更多“思考预算”，适合复杂任务。 9. 文档化一切 让 Claude 记录思路、任务、设计等到中间文档，便于后续追溯和上下文补充。 10. 频繁使用 Git 进行版本控制 Claude 可帮写 commit message，AI 辅助开发时更要重视版本管理。 11. 优化工作流 ▫ 用 `--resume` 继续会话，保持上下文。 ▫ 用 MCP 服务器或自建工具管理上下文。 ▫ 用 GitHub CLI 获取上下文而非 fetch 工具。 ▫ 用 ccusage 监控用量。 12. 追求快速反馈循环 给模型提供验证机制，减少“奖励劫持”（AI 取巧而非真正解决问题）。 13. 集成到 IDE 体验更像“结对编程”，Claude 可直接与 IDE 工具交互。 14. 消息排队 Claude 处理任务时可继续发送消息，排队等待处理。 15. 注意会话压缩与上下文长度 合理压缩对话，避免丢失重要上下文，建议在自然停顿点进行。 16. 自定义 PR 模板 不要用默认模板，针对项目定制更合适的 PR（pull request) 模板。
AI编程工具激战：Claude Code、Gemini Cli崛起· 901 条信息
#Claude Code #AI 辅助开发 #效率提升 #工作流优化 #版本控制
avatar
wong2
3个月前
需要一个agent帮我在升级npm依赖时检查有没有breaking change
#npm #依赖升级 #breaking change #软件开发 #版本控制
avatar
Baye
3个月前
AI 写代码还会有的一个问题是：因为需求在代码之外（Linear/Jira），在多次迭代中经常出现为了新需求破坏掉旧需求的问题。所以要不把需求也写进代码库中？
#AI #代码 #需求管理 #代码库 #软件开发 #版本控制 #协作开发