Skip to main content

Search: #软件工程

无原创,纯转发
  1. 聪明人的分工:让昂贵模型做规划,便宜模型去执行

    知名开源开发者 shadcn 刚刚开源了一个全新项目——improve

    这是一个非常巧妙的 Agent Skill,它的核心理念是:用你最聪明(也最昂贵)的 AI 模型来做高杠杆的脑力劳动(审计代码、写技术方案),然后把脏活累活(编写代码、跑测试)交给更便宜的 AI 模型去执行。

    这个工具本身绝对不会直接修改你的一行代码,它的产出就是一份清晰、可执行的 Markdown 格式实施方案

    💡 它是如何工作的?

    1. 项目审计 (/improve):高阶模型会深度扫描并分析你的代码库,指出潜在的 Bug、性能瓶颈、安全隐患或技术债,并产出一份按“投入产出比”排序的发现清单。
    2. 制定方案 (plans/):当你挑选出需要解决的问题后,高阶模型会针对每个问题输出一份极其详尽的方案(Plan)。这些方案是“自包含”的,带有明确的验证命令、执行边界和异常中止条件(STOP conditions)。
    3. 分发执行 (/improve execute <plan>):你可以把这些高可读性的方案直接扔给任何便宜的轻量级 AI Agent。轻量级模型只需像个机械的执行者一样,按照步骤修改代码、运行测试,最后向你提交 Pull Request。

    🚀 核心指令一览

    /improve:全局审计并输出优化点。
    /improve quick:快速扫描重点。
    /improve deep:对每个包、每个分类进行详尽审计。
    /improve plan <description>:跳过审计,直接为指定任务编写执行方案。
    /improve execute <plan>:派发给便宜的执行器模型并审核其成果。

    安装方式

    项目支持 Agent Skills 规范:

    npx skills add shadcn/improve
    


    https://github.com/shadcn/improve

    #AI开发 #智能代理 #软件工程 #GitHub开源 #shadcn Agent Skills Overview - Agent Skills
  2. 慢即是快:如何利用 AI 写出更高质量的代码

    很多人认为,AI 编程的意义在于“快”——以最快的速度堆砌出勉强能运行的代码,然后匆忙合并发布。但这种“快”往往伴随着低质量和技术债。

    实际上,大语言模型(LLM)非常灵活,我们完全可以反其道而行之:利用 AI,用更慢的速度写出质量更高的代码。

    以下是这种“慢速 AI 编程”的核心思路:

    让 AI 成为挑剔的 Review 助手:LLM 极其擅长寻找 Bug。你可以通过设置特定的“技能(Skills)”,让多个不同的模型(如 Claude 和 GPT)同时对你的 PR 进行审查并给 Bug 分级,通过交叉验证有效降低误报率。
    主导修复与取舍:根据 AI 反馈的 Bug 列表,优先引导 AI 修复高危和中度漏洞。如果发现架构设计有根本性问题,甚至可以果断放弃现有的 PR 重新构思。
    把“修 Bug”当成探索之旅:这种工作流虽然不会提升你的“开发速度”,但常常会帮你揪出代码库中早已存在的历史遗留 Bug。在解决这些问题的过程中,你会编写更多单测,深入理解系统的边缘情况。

    这并不是那种吹嘘“10倍效率”的浮躁开发方式,而是一种更健康的编程状态:借力 AI,更严谨、更方法论地对待每一行代码,让代码库保持健康。

    下次使用 AI 时,不妨慢下来,试着问问它:“我的这段代码可能会在哪里崩溃?”

    https://nolanlawson.com/2026/05/25/using-ai-to-write-better-code-more-slowly/

    #AI编程 #代码质量 #软件工程 #程序员
  3. 以“推理速度”交付:AI 编程把瓶颈从写代码变成了等模型

    这篇文章的核心观点很直接:AI 编程代理的能力跃迁后,作者交付软件的速度越来越不取决于“敲代码”,而更受限于两件事——模型推理时间(inference time)和少数真正需要深度思考的设计决策。

    作者回顾了今年的变化:从最初“有些提示能一次跑通就很惊喜”,到现在“默认就该一次跑通”。在这种前提下,他甚至不再逐行读代码,而是看执行/修改流,关注系统结构是否合理、关键组件在哪里、整体是否按预期运转。

    文章也给了不少可复用的工作方法:

    先从 CLI 做起:任何产品先做命令行版本,方便代理直接运行验证,形成闭环;核心逻辑稳了再上 UI(比如扩展、App)。
    关键决策是生态与依赖:语言/框架/依赖选对了,代理更容易一次完成;作者常用 TypeScript(Web)、Go(CLI)、Swift(macOS/iOS)。
    更偏向“对话式协作”,而不是复杂流程:先和模型聊清楚、让它探索代码、共创方案,满意后再让它开干;他认为“Plan mode”更像旧时代不得已的手段。
    对比 codex 与 Opus:codex 常会先长时间读代码再动手,虽然更慢但更稳,尤其适合大型功能和重构;Opus 更“急”,适合小改动但更容易漏上下文。
    迭代式构建,不依赖回滚:不喜欢 checkpoint/频繁 revert,更多是让模型继续改、继续朝更好的方向“绕山而上”。
    自动化与多项目并行:同时推进多个项目,用队列把想法排进去;瓶颈往往是人而不是编排系统。
    配置思路:提高工具输出 token 上限、合理设置自动压缩阈值,让模型能一次读更多文件;作者强调新压缩机制更可靠,甚至像一次“复查”。

    如果用一句话总结:当“写代码”越来越像可并行外包给代理的体力活,工程师的价值更集中在选型、架构、数据流、约束定义与验收标准上;而真正影响交付速度的,往往是推理等待时间和你是否想清楚要做什么。

    原链接:https://steipete.me/posts/2025/shipping-at-inference-speed
    #AI编程 #Codex #开发工作流 #效率工具 #软件工程 Shipping at Inference-Speed | Peter Steinberger
  4. 代码变便宜了,但“软件”依旧很贵

    AI 工具把“写代码”的门槛打穿了:越来越多人用 CLI/对话式方式,直接描述需求就能生成一个能跑的应用。结果不是 SaaS 的黄金时代,而是“个人软件”的兴起——为某个具体问题快速做一个小工具,用完就丢,像当年的电子表格一样当作临时工作台。

    但别误会:代码的成本下降,不代表软件的成本下降。真正昂贵的是把东西做成能长期运行、能承受现实摩擦的系统:维护、边界情况、体验债、数据归属与同步、可靠性与扩展性。周末做出的 CRUD+API Demo 很好看,但银行 CSV 格式一变、网页 DOM 一改、离线与多端同步一上,脆弱性立刻暴露。

    当“能写出来”不再稀缺,新的瓶颈转向两件事:

    分发与注意力:噪音变大,“一下午做出月入五位数”的叙事很多是营销而非可复制路径。
    判断力与系统能力:工程师的价值更偏向架构与取舍——知道该如何组织系统、何时做限流/缓存、哪些变量不能乱放、哪些复杂度必须正面处理。

    谁会在这波变化中受益?有明确领域痛点的专业人士、需要快速解决内部流程的团队、想替换脆弱手工流程的重度用户,以及愿意为“可控与所有权”而不是“高光界面”买单的人。AI 很能加速,但仍需要像审 PR 一样严格复核:它能产出代码,却不负责让软件在现实中长期站住。

    原文链接:https://www.chrisgregori.dev/opinion/code-is-cheap-now-software-isnt

    #AI工具 #软件工程 #产品分发 #架构思维 #个人软件 Code Is Cheap Now. Software Isn’t.
  5. Claude Opus 4.5:让“能做”突然变得很容易

    作者分享了一个明显的转折:三个月前他还不相信“AI 代理能替代开发者”,但在体验 Claude Opus 4.5 后,他开始认为这件事正在发生——至少在相当一部分软件开发场景里。

    他用几个真实项目说明差异不在“会写代码”,而在于一次成功率、能自我迭代、能把复杂系统拼起来

    Windows 右键图片格式转换工具:从文件资源管理器菜单到打包、安装/卸载脚本、发布网站、GitHub Actions 自动发布,整体接近“一次成型”。遇到报错会自己用 dotnet 构建、读错误、再修复。
    录屏与简单剪辑工具:从类似 LICEcap 的录制开始,持续加到视频/图片编辑、裁剪、模糊、标注等功能,作者感叹“几小时就推进到很远”。
    AI 发帖工具(给小生意用):iOS 端批量上传照片→AI 生成文案→定时发到 Facebook。后端涉及认证、存储、云函数、日志排错等一堆“胶水活”,但模型能通过 CLI 自己创建资源、查日志并修问题,还顺手做了管理后台。
    订单与路线追踪:解析 Gmail 订单、规划路线、统计行驶时间(用于税务),作者强调:这种“手写很痛苦”的 Google/Firebase 集成,Opus 4.5 反而很顺。

    文章也没有回避争议点:
    作者承认自己并不完全理解这些应用“内部怎么搭起来的”(比如 Swift 不熟),但他的焦虑在减轻——因为当问题出现时,模型往往能定位并修复自己的 bug。于是他提出一个更激进的想法:代码也许不必主要面向人类可读,而是面向 LLM 可推理、可重写、可调试

    他甚至分享了一份自用的“AI-first 编码”提示词要点(概念层面):

    • 追求可预测、可调试、低耦合、入口清晰、控制流线性
    • 少炫技抽象,减少层级与间接性
    • 该删就删;重构也要分高/中/低优先级
    • 安全需要更谨慎:API key、登录流程、敏感数据存储等不能盲信

    结尾的态度是复杂的:既兴奋于“几小时能做出过去要几周/月的东西”,也沮丧于技能壁垒被压平。但他给出的建议很朴素:别等“都懂了”再开始,继续做东西,只是更快了;同时一定盯紧安全与密钥。

    原文链接:https://burkeholland.github.io/posts/opus-4-5-change-everything/

    #AI编程 #开发者工具 #Claude #软件工程 #生产力 Opus 4.5 is going to change everything
  6. Agent-native 应用:把“功能”变成“结果”

    这篇文章提出一种新范式:与其把产品能力写成一堆固定功能,不如构建一个能反复调用工具、直到达成目标的“软件代理(agent)”。核心在于:让代理拥有与用户同等的操作能力(UI 能做的,代理也能通过工具做到),并把工具设计成足够原子化的“积木”。这样,新功能往往不再是写代码,而是写一段描述结果的提示词;同时,用户提出的意外需求会推动系统“涌现”出新用法,并反过来指导你补齐工具与能力缺口。

    五个核心原则

    对等(Parity):任何 UI 动作,代理都应能通过工具实现同样的结果;否则代理会卡死。
    粒度(Granularity):工具是原子能力;“功能”是代理在循环中用工具达成的结果。改行为优先改提示词,而不是重构代码。
    可组合(Composability):有了原子工具 + 对等能力,就能通过新提示词快速拼出新“功能”(开发者/用户都能做)。
    涌现能力(Emergent capability):用户会提你没设计过的需求;代理若能组合工具完成,就是新机会;若失败,则暴露工具缺口。
    持续变好(Improvement over time):通过沉淀上下文(context 文件)与迭代提示词,应用可在不发版的情况下持续变强。

    落地方法(把原则变成工程实践)

    先做“能力地图”:列出用户能做的事,逐项确认代理具备创建/读取/更新/删除(CRUD)能力,避免“能新建不能修改/删除”的断腿体验。
    先原语、后领域工具:先用文件、bash、读写等基础工具跑通;再为高频模式加领域工具,用于效率、校验、术语锚定,但不要把“判断”写进工具里。
    文件作为通用接口:文件天然可读、可审计、可迁移,代理也最擅长操作;内容放文件、结构化高频数据放数据库(或混合:文件作可读真相,DB 做索引与性能)。
    明确完成信号:不要靠“看起来差不多了”判断结束;让工具/编排层返回明确的 complete 信号,避免无限循环或半成品。
    透明的代理行为:工具调用、进度、状态变化要让 UI 可见;“沉默的代理”会让用户觉得坏了。
    把“授权”做成产品能力:根据风险与可逆性决定自动执行还是强确认;尤其是发送邮件、发布内容等高风险动作。

    对移动端的启示

    • 移动应用容易被后台杀死,代理任务却可能很长:需要checkpoint/恢复机制,尽可能在每次工具结果后存档。
    • iCloud 之类的文件同步能让多设备共享“同一工作区”,但要处理冲突与未下载文件等边界。

    原链接:https://every.to/guides/agent-native

    #AgentNative #软件代理 #AI产品 #工具调用 #产品架构 Agent-native Architectures
  7. 用好编码代理:Claude Code 2.0 的关键功能与“上下文工程”心法

    这篇长文把 Claude Code 2.0 当成一个“能动手的工作台”来拆解:不仅讲新功能,更强调如何用更好的流程与上下文管理,让代理稳定产出。

    1) 先换个视角:你不是“追上更新”,而是“借力变强”

    作者给了一个更实用的框架:

    跟进工具:定期用、定期看更新(不必天天追)。
    深耕领域:懂业务/系统设计/工程习惯,才能把“未知”变成“可提问、可验证”。
    多玩多试:用不同模型做同一件事,快速建立直觉与边界。

    2) Claude Code 2.0 值得关注的体验升级

    一些偏“日常效率”的改动,叠加起来很实用:

    语法高亮 + 更舒服的评审体验(作者因此更愿意在 CLI 里完成 review)
    /context 看上下文占用(建议复杂任务到 60% 左右就交接或压缩)
    Checkpointing(Esc+Esc / /rewind:能回到某个检查点,回滚代码与对话
    Prompt suggestions / 历史搜索(Ctrl + R:减少重复输入
    更快的模糊文件搜索、队列导航、LSP 插件

    3) Sub-agents(子代理)怎么用才不浪费

    作者重点讲了“子代理不是魔法,是上下文与工具调用策略”:

    Explore:偏“只读搜索专家”,适合快速扫代码库、定位文件与线索。
    general-purpose / plan:更像“全能协作者”,通常会继承更多上下文。
    • 关键提醒:不要只依赖 Explore 的摘要。摘要是“有损压缩”,重要文件最好让主代理再读一遍,让信息彼此“交叉注意力”,推理更稳。

    4) 核心概念:Context Engineering(上下文工程)

    代理之所以“烧 tokens”,不是它话多,而是:

    工具调用本身 + 工具返回结果都会进入上下文;
    • 上下文越长,检索与注意力越容易退化(作者称为 context rot / degradation)。

    因此,上下文工程的目标是:

    • 把最相关的信息放进来
    • 控制“噪音”和重复指令
    • 用清晰结构(计划、scratchpad、handoff)对抗跑偏

    5) Hooks / Skills / MCP:把“提示词”产品化

    作者把这三者放在一起看:

    Hooks:在对话生命周期某个节点自动触发脚本(比如 Stop 后自动提醒/继续下一步)。
    Skills:把领域指令与脚本做成“按需加载”的技能包,避免常驻系统提示导致上下文膨胀。
    MCP:连接外部工具/服务,但要注意“工具定义与中间结果”同样会吃上下文与成本;文中也提到用代码执行环境来降低这种膨胀的思路。

    6) 一个很实战的工作流建议

    作者的默认搭配大意是:

    Claude(Opus 4.5)偏执行与沟通:更像结对编程伙伴、反馈快。
    Codex 偏 review/找 bug:更克制、误报少,适合做“第二视角审查”。
    • 面对难功能:先跑一个“可丢弃的草稿版本”,用它暴露模型的偏差,再用更精准的提示第二轮迭代。

    原文链接:https://sankalp.bearblog.dev/my-experience-with-claude-code-20-and-how-to-get-better-at-using-coding-agents/

    #ClaudeCode #编码代理 #上下文工程 #AI工具 #软件工程
  8. 2025 年 AI 编程现状:效率在涨,工具与模型在分化

    Greptile 发布的《The State of AI Coding 2025》梳理了 AI 编程在 2025 年的关键趋势:工程产出显著提升,开发工具生态快速扩张,而不同大模型在“响应速度、吞吐、成本”上的取舍越来越清晰。

    1) 工程效率:PR 更大,个人产出更高

    PR 规模变大:2025 年 3 月到 11 月,PR 的中位改动行数从 57 增至 76,约 +33%
    开发者产出上升:人均代码产出从 4,450 增至 7,839 行,约 +76%,AI 工具被视为“产能放大器”。
    中型团队提升更明显:6–15 人团队的人均产出从 7,005 增至 13,227 行,约 +89%
    单文件改动更密:每个文件的改动行数中位数从 18 增至 22,约 +20%,说明 PR 不只变大,也更“集中”。

    2) 工具采用:从“能用”到“形成标准层”

    记忆/Memory 基建mem059% 份额领跑(按 PyPI + npm 月下载量口径)。
    向量数据库:没有绝对赢家;Weaviate 约 25%,其余多家在 10–25% 之间拉锯。
    AI 规则文件CLAUDE.md 使用率 67%;不少团队多格式并存,且 17% 的仓库三种格式都用
    AI SDK 增长:Anthropic SDK 以 43M 下载领先(约 8 倍增长);Pydantic AI 增长 3.7×6M
    LLMOps:LiteLLM 月下载量增长 41M(LangSmith 与 LangChain 安装存在绑定关系)。

    3) 模型格局:生态差距在收敛

    SDK 下载量:OpenAI 约 130M 领先;Anthropic 自 2023 年 4 月起增长 1,547×;Google 约 13.6M
    差距缩小:OpenAI 与 Anthropic 的下载量比从 2024 年 1 月的 47:1,降至 2025 年 11 月的 4.2:1

    4) 作为“编程 Agent 后端”,模型各有侧重

    报告用统一参数对多模型做了延迟、吞吐、成本等基准:

    首 token 响应(TTFT):Claude Sonnet/Opus(p50 < 2.5s)明显更快,更利于交互式编程保持“心流”。
    生成吞吐:GPT-5 Codex / GPT-5.1 吞吐更高,长输出更快结束,利于并行跑更多 Agent/CI。
    成本倍率(以 GPT-5 Codex = 1× 归一):GPT-5 Codex ≈ GPT-5.1(1×);Gemini 3 Pro(1.4×);Sonnet 4.5(2×);Opus 4.5(3.3×)。

    结论很直接:选型不再是“谁最强”,而是你更在意 响应速度、吞吐效率,还是预算

    5) 研究方向:规模、上下文与 Agent 的“系统工程”

    报告还汇总了 2025 年影响工具与应用的一批研究线索,包括:

    MoE 的效率设计(如 DeepSeek-V3:关注 KV cache、路由与训练信号密度)。
    长上下文 vs RAG 的边界(不同数据结构下各有优势;以及 KV 级检索等新思路)。
    Agent 训练与检索策略(用 RL 学会“何时搜索”、如何管理长程记忆、如何降低噪声上下文干扰等)。

    原文链接:https://www.greptile.com/state-of-ai-coding-2025

    #AI编程 #开发效率 #LLM工具链 #模型评测 #软件工程趋势 AI Code Review | Greptile | Merge 4X Faster, Catch 3X More Bugs
  9. Beyond Vibe Coding:AI 辅助开发完整指南

    Google 工程负责人 Addy Osmani 发布了一份全面的 AI 辅助开发指南,帮助开发者从"氛围编程"迈向生产级工程实践。

    核心观点

    70% 问题:AI 能快速完成 70% 的功能原型,但剩余 30% 需要深厚的工程知识。修一个 bug 可能引入新问题,安全漏洞风险也不容忽视。

    AI 开发光谱

    自动补全:预测下一行代码
    聊天机器人:自然语言问答
    智能代理:自主处理多步骤任务

    关键最佳实践

    1️⃣ 先规划,后编码:让 AI 先提供架构方案,而非直接生成代码
    2️⃣ 上下文为王:提供相关代码、设计文档、错误信息
    3️⃣ 视觉辅助:截图胜过千言万语
    4️⃣ 每次改动后测试:小步快跑,避免调试噩梦
    5️⃣ 清晰描述意图:说明你想实现什么,而非仅描述表面症状

    进阶技巧

    提示工程:分解复杂任务、提供输入输出示例、善用角色扮演
    上下文工程:像操作系统管理内存一样动态组装信息
    CLI 代理:Claude Code、Gemini CLI 等工具让终端成为强大的开发环境
    多代理协作:不同专业代理并行处理任务

    生产就绪原则

    ⚠️ 始终审查 AI 生成的代码——像审查初级开发者的代码一样
    🔒 安全第一:输入验证、凭证管理、SQL 注入防护

    未来的模型只会越来越强大。今天学会与 AI 协作,就是在为明天的工程实践做准备。

    🔗 原文链接

    #AI辅助开发 #VibeCoding #提示工程 #软件工程 #AddyOsmani
  10. 规范驱动开发(SDD)的局限性

    随着 AI 编程的兴起,一种旧模式正在回归:编写详细的规范文档(Spec),然后期望 AI 能稳定地生成“正确”的代码。然而,这种规范驱动开发(Spec-Driven Development, SDD)在实践中往往会碰壁,原因与当年瀑布流开发模式失败类似——现实的变化总比规范文档快。

    为什么规范驱动开发会失败?

    1️⃣ 维护成本高昂
    编写详尽的规范耗时巨大,而且在需求变更、约束调整时,保持规范与代码同步会产生巨大的维护成本,有时甚至会加倍工作量。

    2️⃣ 规范无法反映所有上下文
    规范描述了系统“做什么”,却无法解释“为什么”这么做。而“为什么”恰恰承载了关键背景信息,如技术权衡、团队在迭代中的学习、以及塑造解决方案的现实约束。

    3️⃣ 过度规范化造成虚假的安全感
    一份详细的规范会给人一种“一切尽在掌握”的错觉,但这往往是虚假的。软件开发是一个探索性过程,最重要的洞见往往在构建开始后才会出现。

    4️⃣ 抽象层次错误
    多数 SDD 工具关注的是实现的细节(“如何做”),比如字段定义、函数签名等,但更重要的是其背后的意图、约束和上下文(“为什么做”)。

    什么才是真正重要的?—— 上下文工程

    文章认为,AI 编程缺失的不是更详细的规范,而是更完善的上下文保留。AI 原生的开发流程应该:

    • 从意图出发,明确要解决的问题和核心约束。
    • 保持上下文的实时更新,让团队与 AI 保持同步。
    • 让规范跟随代码库,成为动态演进的文档。
    • 保留决策背后的“为什么”,而不仅仅是需求。

    总而言之,对于需求稳定、边界清晰的领域,SDD 是有效的。但对于不断演化的探索性开发,上下文驱动的方法能更好地适应变化。

    原文链接:https://isoform.ai/blog/the-limits-of-spec-driven-development

    #AI #软件开发 #编程 #规范驱动开发 The Limits of Spec-Driven Development - Isoform
  11. 如何让 AI Agent 高效处理长期复杂任务?

    当 AI 智能体(Agent)处理需要数小时甚至数天的复杂任务时,它们常常会因为上下文窗口的限制而“失忆”,导致工作中断、效率低下。Anthropic 从人类软件工程师的协作模式中汲取灵感,设计了一套有效的解决方案。

    核心方法分为两步:

    1️⃣ 初始化智能体(Initializer Agent)
    在任务开始时,该智能体首先搭建好整个工作环境。它会:
    - 分解任务:将用户的高级指令分解成一个详尽的功能列表(features list)并存入 JSON 文件。
    - 建立基础:创建 init.sh 启动脚本、claude-progress.txt 进度日志文件,并完成首次 Git 提交。
    这确保了后续工作有清晰的目标和坚实的基础,避免了 Agent 试图一次性完成所有工作或过早宣布任务完成。

    2️⃣ 编码智能体(Coding Agent)
    在后续的每一个会话中,编码智能体都遵循“小步快跑”的原则:
    - 聚焦单点:每次只专注于实现功能列表中的一项。
    - 记录进展:完成一项功能后,通过 Git 提交代码并附上清晰的说明,同时更新进度日志文件。
    - 严格测试:利用 Puppeteer 等浏览器自动化工具进行端到端测试,确保代码质量。

    这种“初始化 + 增量编码”的模式,让每个 Agent 在开始新会话时,都能通过阅读日志和功能列表快速了解项目状态,确保工作连贯、高效。它有效地解决了 AI Agent 在长期任务中的一致性问题,使其能像一个纪律严明的工程团队一样协作。

    阅读原文

    #AI #Agent #LLM #Anthropic #软件工程 Effective harnesses for long-running agents
  12. 这篇文章探讨了“制造软件”的真正含义. 作者认为,这远不止是编写代码,而是一个发现、创造和交付价值的完整过程. 它始于深入理解问题和用户需求,终于创造出能为他人生活带来积极改变的工具.

    真正的挑战在于处理那些模糊不清、充满人性的部分:理解混乱的需求、平衡不同的观点、并在不断变化的环境中找到前进的道路.

    软件开发是一门手艺,它结合了解决问题的智慧和创造有用工具的乐趣. 从一个想法到最终产品,这个过程充满了挑战,但也带来了巨大的满足感.

    原文链接:Making Software

    #软件开发 #产品思维 #编程 #创造力
1px