← 返回信息流
Agent SkillLINUX DO · AI·2 小时前

非科班小白用AI开发ERP系统,求Git与架构学习建议

原标题:刚接触 AI 编程,完成了一个 ERP+CRM 系统,但很迷茫,向各位佬友求点经验

速览

一名供应链公司职员利用AI编程工具结合Odoo框架完成了ERP+CRM系统开发。尽管实现了功能,但作者因缺乏代码底层理解及架构意识,在维护与扩展时感到迷茫。作者重点请教了Git分支管理策略、软件架构设计原则以及AI编程技能的副业发展路径。

AI 深度解读

背景

作者是一名非计算机科班出身的供应链公司职员,近期开始接触 AI 编程。在老板的指派下,利用开源框架 Odoo 进行定制开发,以替换即将到期的公司 ERP 系统。作者通过 B 站学习 Python 基础,并借助 Codex 等 AI 工具,通过“描述问题”、“提出功能需求”和“错误分析修改”三个主要交互步骤,成功构建了一个包含 ERP 和 CRM 功能的系统。

尽管系统得以实现,作者意识到自己虽然能借助 AI 完成功能,但缺乏对代码底层逻辑的理解以及项目整体架构的把控能力。面对版本更新、功能冲突或复杂问题时容易迷失方向。因此,作者希望向社区请教关于 Git 版本管理、架构意识的理解、以及 AI 编程技能的职业发展与副业可能性。

核心内容

作者详细阐述了从零基础到利用 AI 完成企业级系统开发的经历,并提出了四个核心困惑:

  1. Git 版本管理的具体实践: 作者了解到 Git 是版本管理的标准工具,并观察到社区中常提及“热修复”、“系统开发”、“代码优化”等不同分支类型。其理解是:在版本更新时,将开发分支合并。作者希望确认这种工作流是否正确,以及如何规范地管理不同场景下的分支策略。

  2. 对“架构意识”的理解与验证: 作者将架构意识分为两个层面进行自我验证:

    • 技术选择层面:根据项目需求,了解不同编程语言、框架和技术栈的优缺点及适用场景,从而做出合理选型。
    • 项目层级与关系层面:厘清前端页面交互、后端功能调用关联、数据库数据保存与调用逻辑、以及底层函数计算逻辑之间的关系。 作者询问这种理解是否准确,并寻求判断项目架构合理性的标准及新手学习路线。
  3. 技能变现与职业发展: 作者希望了解是否可以将 AI 编程技能转化为副业或兼职收入来源,并询问如何进一步提升该能力,使其成为个人竞争优势。

  4. 知识体系构建的缺失: 作者承认目前对函数、框架概念仅有模糊认识,未形成完整知识体系,导致在 AI 辅助编程中处于“知其然不知其所以然”的状态,难以应对复杂问题。

关键要点

  • AI 编程的双刃剑效应:AI 工具(如 Codex)能显著降低开发门槛,帮助非科班人员快速实现功能(如基于 Odoo 的 ERP+CRM 系统),但容易导致开发者产生依赖,缺乏对代码逻辑和整体架构的深度理解。
  • 版本管理误区澄清:Git 分支策略并非简单的“开发分支合并”,通常涉及 main/master(主分支)、develop(开发分支)、feature/*(功能分支)、hotfix/*(热修复分支)等规范流程,需根据团队协作和发布周期制定策略。
  • 架构意识的多维性
    • 横向:技术栈选型(语言、框架、数据库)需匹配业务场景。
    • 纵向:分层架构(前端、后端、数据库、底层逻辑)需职责清晰、耦合度低。
    • 合理性判断:通常依据可维护性、可扩展性、性能表现及代码规范来评估。
  • 学习路径建议:从“AI 辅助实现”转向“理解实现原理”,需要补充计算机科学基础、设计模式、系统架构设计等知识,建立完整的知识体系。
  • 职业前景:AI 编程能力正成为新兴优势,结合垂直领域知识(如供应链、ERP 业务逻辑),可探索自由职业、独立开发或企业内部提效等方向,但需提升解决复杂问题和系统设计的核心竞争力。

意义与影响

该案例典型地反映了 AI 时代非技术人员进入软件开发领域的机遇与挑战。它揭示了“低代码/AI 辅助编程”在 democratize 开发能力方面的巨大潜力,同时也暴露了由此带来的“黑盒化”风险——即开发者可能沦为 AI 的“提示词工程师”,而丧失对系统本质的掌控力。

对于社区而言,此帖引发了关于 AI 编程下开发者核心能力重构的讨论:

  1. 技能转型:传统编程技能(语法、调试)的重要性相对下降,而系统思维、架构设计、问题拆解及 AI 协作能力变得更为关键。
  2. 教育启示:技术学习不应仅停留在工具使用层面,更需深入底层原理,以应对 AI 无法完全解决的复杂系统问题。
  3. 职业生态:AI 降低了创业和副业的门槛,但长期竞争力仍取决于对业务逻辑的深刻理解和对技术架构的精准把控。

此帖为其他类似背景的开发者提供了宝贵的参考,强调了在享受 AI 红利的同时,必须主动构建扎实的技术根基和架构思维,以实现从“使用者”到“掌控者”的转变。

查看原文 →linux.do