AI 如何改变程序员与软件公司:圆桌会议纪要

这场约两小时的土耳其语圆桌，从 AI 对日常开发的影响谈起，随后进入招聘、软件销售、客户自建、开发者转型与团队组织，最后由听众提出云成本、ABP 和新人求职等具体问题。

本文按会议推进顺序整理，保留主要问题、回应和分歧。涉及市场趋势与未来预测的内容，均来自嘉宾经验，不是行业统计结论。文末另设作者评论。

参与者与讨论背景

Halil İbrahim Kalkan 是本场主持人、Volosoft 联合创始人、ABP Framework 首席架构师，也是《Mastering ABP Framework》作者。他有软件开发、技术团队管理、产品开发与全球销售经历，讨论中经常追问开发提速怎样转化为交付和经营成果。个人网站^[1]、LinkedIn^[2]

Gökhan Şengün 是独立 DevOps 顾问，早期从事嵌入式与应用开发，之后转向 DevOps、云技术和平台工程。他通过咨询接触不同企业，关注持续交付、性能与系统可靠性，也观察开发提速后平台和运维工作承受的变化。个人介绍^[3]、LinkedIn^[4]

Uğur Umutluoğlu 是 Devnot 创办人与活动组织者，也是技术招聘机构 TalentOps 的创始人。他的经历横跨开发、团队管理、咨询、招聘与开发者社区，带来企业用人需求和求职者反馈的视角。Devnot^[5]、个人资料^[6]、活动主办方介绍^[7]

Enis Necipoğlu 在 Volosoft 从事软件开发，主要参与 ABP Framework 工作，也是 UraniumUI、InputKit、AutoFilterer 等开源项目的开发者。他在访谈中提到，自己参与过 ABP 商业版多个模块和产品，为讨论补充了一线工程实践。本人 GitHub^[8]、LinkedIn^[9]

一、Gökhan 的开场观察：需求跟上了，工作却没有减少

Halil 先说明，讨论既包括工具使用，也包括开发、测试、交付和软件公司的经营。介绍参与者后，他请 Gökhan 谈 AI 带来的变化。

Gökhan 的第一个观察是，团队终于更有能力回应业务部门的要求。过去经常出现需求做不完、交付慢、质量不稳定的抱怨；现在，模型与执行工具进步，让一些原本没有时间、人手或预算开展的项目重新进入计划。

在平台开发工作中，他也更容易提前测试、检查边界情况。但这种能力没有自动换来更少的工作。他说，自己的工时反而达到以前的大约一点五倍。客户和安全研究人员也在使用 AI，会更快发现问题、提出改动，开发团队需要同步回应。

常规操作减少之后，留给人的更多是决策、风险判断和上下文切换。一个人可以同时启动更多任务，却不一定有更多精力处理它们。

Halil 随后追问：人均工作增加以后，团队究竟缩小了，还是继续招聘？Gökhan 回答，AI 的影响与土耳其经济收缩重叠，很难完全拆开。有资金、有客户、能卖出产品的公司，仍然在推进和招人。

他举了一个具体变化：过去平台团队等开发者完成工作，现在开发者反而催促平台团队尽快部署。效率提升把压力传向了下一环节。不过，对于最终产出增长多少，他没有经过测量的数字。

二、招聘讨论：为什么初级岗位更受冲击

主持人顺着用人变化，把问题交给 Uğur。Uğur 结合招聘和社区交流描述，市场低迷并非只出现在个别公司，资深机会也在减少，但初级与经验较少的人压力更大。

他回顾，自己较早时更倾向于把低迷归因于经济，后来越来越直接地感受到 AI 对招聘决策的影响。同时，他提醒，职位列表不一定代表立即招人，其中可能包含企业形象、未来储备等需要。

初级岗位受到挤压，涉及几个叠加因素：培养新人需要时间和指导投入；一部分入门任务已经能交给 AI；市场上经验丰富、急于求职的人增加，企业更容易选择能立即上手的候选人。

这也留下长期问题：如果大家都减少新人培养，未来的资深人才从哪里来？Uğur 没有给出确定答案，也保留了工具继续发展后，人员需求结构本身改变的可能。

Halil 则提出另一面：AI 也给新人增加了能力，可能缩短适应周期。经济环境改善后，新增软件需求是否又会平衡人员需求的下降？这两个问题没有当场解决，后面多次回到它们。

三、Enis 谈技术变化，Halil 补充判断与决策负担

主持人接着请 Enis 从技术角度解释，为什么近期影响变得更加明显。Enis 回顾，早期工具主要补全代码，现在已能围绕目标推进实现、运行测试、发现错误并继续修正。

这类能够调用工具、持续执行任务的 AI，通常被称为智能体。能力变化不只来自模型回答得更好，也来自读取项目、执行命令和获得反馈等环节连接起来。但 Enis 仍强调，需要人提出目标、提供条件并管理执行。

Halil 随后谈到自己的试用经历，并特别提到 Opus 4.5。他给出了相当强的个人判断：当前工具已不能只当作初级助手，在许多自己能完成的技术实现上，工具也能完成，甚至做得更好。他认为，应先接受变化，再讨论接下来怎样工作。

回到新人问题时，他区分了两种困难：技术能力不足，以及不了解产品、公司目标和既有经验。AI 能缓解前者，却不能自动让新人知道一个取舍为什么符合业务需要。

他也回应了工作更累的感受：常规实现减少后，人的工作更集中在决定、判断和同时管理多个任务。有时深夜还想给 AI 留最后一个任务，让它做到早上，但躺下以后，那件事仍然挂在脑子里。

这一轮结束时，主持人把问题从产出转向经营：大家做出了更多软件，这些软件能不能卖出去？

四、软件卖给谁：从克隆功能谈到产品责任

Uğur 接过问题后，强调产品开发和采购中的技术之外的工作：找到客户、了解需要、解释产品、回答疑问，以及完成购买决定，仍然包含大量沟通。

对“一周克隆一个 SaaS”的说法，他区分了功能相似与能够长期经营。早年某类内容网站流行时，也会出现大量模仿者，但不少很快消失。进入门槛下降，并不保证每个产品都能建立用户和收入。

讨论随后推进了一步：服务商的压力不一定来自新竞品，也可能来自客户不再购买。有嘉宾说，一些原本会订阅的小工具，现在可以考虑用 AI 自己实现。为自己解决问题，与做产品出售不同，却同样会改变原有收入。

接着，会议讨论了标准化和定制化。现成产品能让客户快速开始，却未必覆盖其最重要的个性化需要。AI 让补充和改写功能更容易，因此会改变“买现成的还是自己做”的选择。

但个人小工具与企业系统要求不同。多人使用时的权限、数据、流程和持续运行，仍然需要处理。能让演示工作，不代表已经完成生产环境里的全部要求。

在可扩展平台的话题下，现场用 Volobox 举例：应用可以有自己的前端和数据，通过事件、接口连接；认证、通知、收件箱、审批和待办等公共能力，则由底座提供。讨论还设想，未来模板可能加入业务领域的结构、给 AI 的说明和配套工具。

这些是产品与工具形态的探索，没有在现场形成完整路线图。随后的发言再次把重点拉回责任：监控、托管、维护、支持、服务承诺和备份，需要有人长期承担。克隆来自己用，与克隆来出售，不能只用生成速度衡量。

会议因此追问，软件公司未来能否更多地通过可靠运行、定制支持、公共能力与持续服务收费。技术上做得出来之后，客户为什么购买、出了问题找谁，仍然需要回答。

五、需求是否会扩大：乐观与谨慎的判断同时存在

产品化讨论之后，会议回到此前的问题：如果开发成本下降、经济环境恢复，过去做不起的项目会不会被释放出来，从而吸收一部分受冲击的开发者？

较乐观的思路是，原来不划算的需求现在可能成立，新产品和公司也可能增加。Uğur 用移动应用的兴起作类比，并设想医疗、制造、国防等领域未来可能创造新的工作。

但主持人又追问，如果小团队借助 AI 已能完成任务，公司为什么还要维持过去的大团队？更多产品不必然带来同比例的招聘，需要有足够多的新业务真正成立。

对于市场恢复，现场也有保留：即使重新活跃，过去招聘与薪资快速增长的阶段，未必原样回来。买方预算不足，同样会限制产品销售。

Halil 还提出，不必只等待未来行业。眼下很多企业连原有数字化都没有完成，仍在用表格、文档和纸笔开展工作。开发者可能更多地帮助这些企业落地 AI、连接业务与技术。这个方向，随后又引出了角色转型的问题。

六、成本插问之后，会议谈到工资与议价能力

在继续讨论角色之前，有人先提出 AI 成本问题：高强度 API 调用并不一定便宜。如果工具成本接近雇人成本，用人选择会不会再次变化？回应中也有人认为，技术优化和本地部署可能降低成本。现场没有形成长期价格判断。

随后，话题转向薪资。招聘视角的发言指出，过去企业难以招人时，开发者议价能力较强；如今职位减少、候选人增加，企业可能用较低报价找到更有经验的人，初级机会也进一步受到挤压。

讨论把这一变化与软件公司的收入、竞争和定价压力联系起来。有嘉宾据此担心普遍的高薪预期难以维持，但也强调，不同人员的能力与价值仍有差别。

发言者同时解释，分享候选人反馈和企业报价，是描述所见市场，并不等于希望开发者收入下降。会议没有给出可以适用于所有岗位的工资预测。

七、回到开发者转型：理解业务、参与决定、跟进交付

Halil 随后回到被打断的问题：除了等待新岗位，现有开发者要怎样变化，才能在新的工作方式里持续贡献？

讨论中出现了更多小公司、小团队甚至一人公司的可能。与此同时，不同企业的要求仍然不同：销售软件产品的公司，与靠其他业务收入运行、拥有内部软件团队的公司，面对的客户和经营问题并不一样。

有发言强调，即使客户自己也能使用 AI，仍然需要有人承诺把事情完成，并负责处理结果。这使开发者的职责延伸到问题定义、方案取舍、验证和实际使用。

能力结构也被重新讨论。有嘉宾更强调系统认识和架构判断，认为不必精通每个框架的全部细节，但需要知道各环节怎样配合，能够解释自己要什么。另一个侧重是业务领域的深度：理解电商、金融或 ERP 的规则，才能提供正确背景并判断结果。

Gökhan 接着强调沟通。他认为，过去单靠强编码能力、却不愿与人合作的工作方式，会承受更大压力。理解对方需要、解释问题、促成决定和推进交付，会更加重要。

主持人把这一点具体化：拿到大致要求后，能细化需求、梳理决策点、讨论风险，并跟进测试、部署和客户怎样使用的人，仍有明显价值。只把要求转交给工具、把判断与检查留给别人，则需要重新解释自己的贡献。

在后续补充中，Uğur 谈到企业让分析师参与实现的个案，并提出安全、上下文工程与领域知识等方向。上下文工程，指提供任务背景与约束，并持续发现和纠正偏离。ERP 被用作例子：表关系、业务规则和关键流程的知识，能帮助开发者引导 AI、验证结果。

这一阶段也出现了“不必再像过去那样深入追踪每个技术细节”的强烈判断；后面的面试与封闭环境讨论，又重新强调了独立排错的用途。两种侧重都需要保留。

八、听众提问：云成本、本地服务与实际工作流程

Abdullah 提问，云服务器成本很高，本地团队是否能凭更贴近客户、提供定制与服务，取得相对优势？

Gökhan 回答，需要看业务。一般业务系统的主要成本未必是云资源；视频、音频转码或大量使用 GPU、CPU 的任务，差异则会明显得多。本地数据中心和国际云服务之间，还要比较管理方式、运维与自助能力，不能只看资源报价。

接续发言谈到，采购现成产品与内部开发，需要把人员、维护和定制成本一起考虑。也有人设想，特定软件领域未来可能出现更多标准、监管或本地化要求，影响个人自建和产品采购。这部分是现场预测，没有对应到已经确认会实施的政策。

主持人之后处理了一个文字问题：是否需要用英语与 AI 交流，以节省 token 或获得更好效果？现场回应针对土耳其语与英语的使用体验，认为较新模型上的差别已没有过去明显，没有展开系统比较。

随后，Ahmet 从金融行业的开发经历出发，描述小团队的流程：在 Trello、Jira 或 Linear 建立任务，交给智能体拆分和安排；遇到需要判断的地方，仍由懂业务或技术的人介入，作出决定后再继续实现。

这段分享说明，小团队中的人更多集中在决策与监督上。现场没有完整展开后续交付流程，也没有把它作为通用方案。

九、组织讨论：职责合并后，协作方式也需要改变

听众分享之后，会议进一步讨论，分析、开发、测试和部署，可能越来越多地由同一个人或小团队贯穿负责。

嘉宾认为，规模之外还存在沟通问题。需求复杂、同时处理的事情多，会带来误解、重复讨论和错误决定。减少交接可能提高效率，但成员也需要理解和承担更完整的工作。

有嘉宾结合大型机构的经历，描述团队贡献并不平均，也提到一些人员是为未来项目或组织准备而保留。因此，当前任务量、未来需要与经营条件，会共同影响规模决定，不能直接从个别经验推导统一裁员比例。

Halil 随后追问，如果更少的人已能完成原来的工作，要维持规模，就需要更多项目或产品；而新产品卖给谁，又回到了经营问题。已有稳定收入和内部积压需求的企业，与主要依赖软件销售或人员服务收入的公司，可能作出不同选择。

十、ABP 问答：分析师都能写代码后，框架还有什么价值

Adem 提出公司实践与 ABP 的未来问题

Adem 说，公司里分析师已经开始参与实现，开发者也承担更多分析与测试。他还提到自己看过关于 AI 重复代码的说法，但对其可靠性和适用性并不确信。

Uğur 因行程离开、主持人致谢后，Adem 继续提问：公司使用 ABP 数年，也购买许可证，框架让分析师更容易开发界面与流程。那么，在 AI 生成能力提高、更多角色开始写代码的情况下，Halil 怎样看 ABP 的未来？

Halil 回应基础能力，也承认现成功能需求的变化

Halil 先解释 ABP 为什么仍然有用：没有引导时，AI 可能按照自己的方式组织项目；框架已经提供架构、安全、事件处理等基础能力，直接使用它们，可以让生成工作更集中在业务逻辑上。

他也提醒，深入底层实现时，错误可能表现为安全或并发问题，而不只是界面不符合要求。已有基础能力可以减少重复实现，但这并不保证任何生成结果都自动正确。

回答的另一面同样明确：团队也看到，部分现成模块、主题等能力的需求减少，并在持续讨论这些变化。工程底座与现成功能包，需要分别看待。对于具体路线图，他没有在现场展开，只说明 ABP 仍在变化和发展。

补充讨论转向架构约束、重复代码与评审

另一位嘉宾说明自己也使用 ABP，并补充，不能理解代码输出的人，更容易在生成过程中引入问题。既有架构能够约束工作范围；如果结构本来不清晰，又缺少评审，让更多角色直接提交代码，可能使维护更困难。

他随后提出一个开放问题：过去反对重复代码，是因为修好一处容易漏掉另一处。如果未来 AI 能同步检查和修正相似位置，维护负担会不会改变？这是一种设想，并不是当前可以忽略代码质量的理由。

他的当前态度仍然谨慎：没有良好基础结构，尤其没有评审时，直接放开提交权限仍值得讨论。现场也有人肯定试错的必要，认为工具提高修改速度后，企业可以更快摸索新方法。

这组问答同时保留了基础能力的价值、现成功能需求的变化，以及新开发方式仍需结构和责任约束的判断，没有给出一个定型的未来方案。

十一、求职问答：新人怎样获得经验，企业又怎样判断能力

Emre 的困境与 Halil 的回应

曾在 Volosoft 实习的 Emre 说明，自己仍在工作，但身边一些毕业同学长期没有进入行业，简历很少得到回复。他也担心失去当前岗位以后，能否再找到下一份。

他的核心问题是：招聘要求经验，但第一份工作都找不到，经验从哪里来？AI 能承担越来越多任务后，新人怎样进入公司，企业又会怎样面试和选择他们？

Halil 先承认担忧的现实基础。他说，即使自己从业多年、还有公司，如果当前业务出现严重问题，也会对重新找工作感到不安。一个职位可能收到很多申请，却只录用极少数人；没有回音，不能直接证明每个求职者都没有能力。

他回顾过去的建议：完成一个能从头到尾运行的小项目，理解它怎样做出来，再在面试里讲清楚。但他也立即提出新困难——AI 可以参与大量实现，如今怎样从成品判断候选人本人理解了多少？

作品仍能提供材料，评价方式却需要变化。Halil 没有给出成熟答案，随后请 Gökhan 谈企业应怎样面试和选择开发者。

Gökhan 坦言，目前没有一套普遍有效的入行办法

Gökhan 提醒，不要把行业现状完全理解成个人失败。在他的判断里，眼下企业很难为毫无经验的人承担培养成本，机会可能集中在熟人推荐或确实需要扩充团队的特殊情况。

他也承认，没有真实项目，很难只靠每天安排学习就获得与工作相同的训练。过去直接建议新人学习某门语言，也不足以回应今天的处境。他没有提出保证就业的步骤，只表达了对市场将来重新打开的希望。

日常依赖 AI，面试为什么还限制 AI

Gökhan 随后直接称呼 Halil，介绍他们的面试方式：自己日常已大量让 AI 写代码，面试时却仍要求关闭 Copilot 等工具，观察候选人怎样独立思考和排错。

他没有把这种做法当成已验证的标准，反而承认，面试需要改变，但暂时不知道怎样改，因此仍沿用较熟悉的方式。部分工作环境也无法连接外部 AI，独立解决问题仍有用途。

主持人指出，这种方式更容易判断已经有经验的人，也会倾向于有经验的候选人，又回到了 Emre 最初的问题。随后大家谈到，是否可以允许 AI，改为观察候选人怎样推进任务、思考和引导工具，但尚未形成可靠的评价标准。

基础能力也被再次强调。嘉宾认为，能理解并处理任务的人，往往更能有效使用工具。还有人分享，部分较年轻的开发者因为长期依赖 AI，对过去会处理的调试问题变得生疏。这些是个人观察，并非对所有使用者的统一判断。

Fahri 补充作品与个人展示

临近结束，已进入 Volosoft 工作的应届开发者 Fahri 提出，求职者可以通过专业内容和作品，让别人看到自己的兴趣、能力与表达。他举到 YouTube、Instagram 等渠道，也强调与他人建立交流。

现场随后也有人赞同，拥有一个正在运行的项目，不论大小，都能增加了解候选人的材料。但这些做法没有被表述为获得工作的保证。

结语：会议结束时，哪些问题仍然没有答案

Halil 最后感谢参与者，回到开场的安排：不同工作环节的人分享各自经历，希望帮助大家理解变化。会议没有宣布组织决议、招聘承诺或产品路线图。

贯穿整场的分歧，是新需求能否吸收团队用人减少的影响。较乐观者关注新产品、新企业与传统行业转型，较谨慎者关注团队规模、客户预算和真实招聘。

最后两组问答把这些问题落到了具体处境里：ABP 要同时面对基础能力价值与现成功能需求变化；招聘者自己也仍在寻找新的面试方式，无法为新人提供确定入口。

会议反复回到需求理解、实现、验证、交付和持续责任。工具已经改变许多任务的做法，任务变化最终怎样影响职业和市场，还需要结合具体环境观察。

作者评论与总结

读完这场讨论，我会把三个问题分开：AI 能完成哪些任务，一家公司需要多少人，以及整个市场能提供多少岗位。它们相互影响，但不能只凭一个原型的开发速度，就推断整个职业的命运。

乐观者关注过去没有被满足的需求，谨慎者关注企业怎样招人、客户是否有预算。两种观察都值得保留。对我来说，重要的是看清各自成立的条件，而不是挑一句最强烈的预测来代表整场讨论。

我仍然看重能解释、能验证、能负责的能力。工具减少了手动实现，并没有自动消除理解和排错的需要。基础知识的作用，也体现在提问、选择和检查之中；如果无法理解生成结果，就很难判断省下了多少工作，又留下多少风险。

对于新人，我不愿把困难简单归结为学习不够或展示不足。作品、专业内容和社区交流能够增加被了解的机会，但真实任务、培养意愿和招聘环境同样重要。行业希望持续获得有经验的人，也需要有人创造积累经验的环境。

对于软件公司，我更关注客户为什么持续付费。容易生成的小功能会受到挑战，而业务适配、可靠运行、持续支持与责任承担，需要被清楚说明，也需要真正兑现。平台化是值得观察的尝试，最终还要看客户是否更容易完成工作，定制与维护的负担是否合理。

我希望保留下来的，是这场讨论展开问题的方法：技术上能做到什么，进入团队后会碰到什么，客户为什么购买，出了问题谁负责，以及新人怎样获得经验。持续尝试工具，同时保留理解、验证和承担责任的能力，是我认同的方向。