JetBrains 之 2024 年開發者生態調查，發現三成有開發者日日用六至十種開發工具。Stack Overflow 之 2025 年調查，則稱每開發者日均使用七點三種不同工具。此數未計入層疊之 AI 工具：有 Copilot 以生成代碼，有 ChatGPT 以進行研究，有 Cursor 以進行編輯，有 Claude 以進行代碼審閱，更兼現有工具中嵌入了 AI 功能（VS Code 之 IntelliSense，GitHub 之 PR 總結，Jira 之 AI 創造故事）。
每器有其境，其面，其验，其讯，其识之重。其修之费，乃诸器间境易之积也。
吾御工师三十五至五十人。于器择之见，略述之：器愈寡，愈合，恒胜器繁，联疏之费。
数字之数
JetBrains (2024, n=26,000):
- 三成五之开发者日用具六至十器
- 一成二日用具十一器以上
- 切换诸器之平均时，为工作之时九至十四分之百
Harness (2025 Developer Experience Report):
- 六成二之开发者谓切换诸器之境，乃其生产力之最大损耗
- 凡开发者，时移其境，计十三迁
- 每迁之复，需时十五至廿五刻（据微软及加州大学欧文分校之研，论神思复元）
其算如下： 每时切换上下文十三次，平均恢复时间二十分钟，则恢复之暇多于工作之时。显见开发者未尝于每切换间尽复其神。其心常处于半神之境。其损非以失时计之，乃以生弊量之。盖因开发者心系Slack之警，而审PR之时，而CI之管于背景中败坏，遂致谬误丛生。
何故工具有蔓延
每事有专属之器
众中或遇困厄，寻得器以解之。遂引此器，未尝察旧器已可御此困，新器能否与既有之栈相融，抑或他器之认知负担过重，反失其利。
三载之间，此法所成：以GitHub掌源码，以Jira理项目，以Confluence载文牍，以Slack通消息，以Notion记笔记（盖Confluence迟缓故也），以Linear追事（盖Jira繁复故也），以Figma谋设计，以Storybook明组件，以Datadog察监测，以Sentry缉谬误，以PagerDuty发警讯，以Postman测API，兼各开发者所好之AI器，皆备焉。
此乃十三之器。各器各具一浏览器之标签，一登录之会话，一通知之设置，一心智之模型。各器皆需开发者记其何处寻何信息。
人工智能之器，益彰其弊。
二零二三年，平昔之码匠，用器五七。迨二零二五年，增至七十。增者，几尽乎智器。编修有Copilot，瀏览有ChatGPT，繁思赖Claude，另择Cursor为编修之器。PR之程，有智器以审码。智器所生之文牍，亦备焉。
诸智器皆言可增效率，然无计一境之费。一匠用 Copilot 以生，ChatGPT 以研，复有 AI 之审码器，则除七非智器外，更持三境。是十境也。每境皆扰他境。
调试之税
生产之际，若事有差池——或错误骤增，或性能衰减，或客报之虫——则调试之务，须并合诸器之信息：
- Sentry/Datadog：错何在？端何处？用户何人？
- GitHub：近有何变？何PR合于二十四时之内？
- CI/CD：最新部署是否全数通过测试？有无警示？
- Slack：可有提及相关之问题？此乃已知之困乎？
- 应用日志：服务器日志于失败之请求所示何如？
- 数据库：有无查询性能之问题？迁徙是否已行？
诊生产之弊，须六器为始。每器必启，验其真，询其状，解其意。各器之讯，当凝神相参，盖器器不相语也。
持六窗而瞬息易之者，非善察也。彼犹戏记忆焉：目见Sentry中时戳之谬，复索Datadog中相应之录，继而觅GitHub中匹合之PR，终验部署之先后。每易一窗，则境迁；每失一境，则患生。患生则失其联，失联则罔解其症矣。
此乃调试之税也。非各工器所耗之时也。乃切换工器之间所费之时，及因开发者切换时失其境而错失之连结，致久存之虫也。
吾辈何以应之
减损栈
于EltexSoft，吾辈每项目仅择至简之器，不轻添新器，必先审其心智之耗。
源代码管理：GitHub也。恒也。非GitLab，非Bitbucket，非并置。一地存代码，PR，CI/CD诸务。
项目管理：一器，由客户择之。Jira，Linear，或GitHub Projects也。并行二项目管理器，未尝有也。
通联： Slack（或客户端之聊斋）。无并行通联之径。若言谈于 Slack，其决则录于 Slack。非存于 Confluence 之页，人罕观之。
监察：一可察之台。Datadog 或 Sentry，勿兼用（若项目之规足以当之）。日志、讹误、度数，集于一处。
AI之器，独任其择，然其出必经常法之审。无强令之AI，亦无禁绝之AI。惟代码为要，非所由生之故也.
先合而后增之
欲引新器，先问：旧器可御此否？GitHub Actions代独立之CI器。GitHub Projects代小项目独立之任务追器。Sentry代多数应用独立之日志器。
至善之器，乃已备而足用者。次善之器，乃与旧用相合者。至恶之器，独能精工，然凡他事皆需手动转换情境。
减省调试之域
生产之变生，调试之程当求境换之少。此谓：监测之器中，当布元数据（何为提交，何为合并请求，何工所布）；错谬之迹中，当存错境（全栈之迹，请参之数，用者之境）；且于Slack单道通变事（勿散于五道）。
吾等于诸项目之中，皆设CI/CD之制，于监控之屏显部署之注。若误码之骤增与部署相系，其关联立现一目。开发者无需启GitHub，觅其提交，寻其部署之时，复手动与误码之序时相合。数据已自相联接矣。
无人计其生效之增
吾辈既入客户之务，减工具之堆自十二至七，其效增实矣，然鲜有量之者。人莫言"吾辈去冗杂之器，得省十四分之工时"，惟言"众工似速"，或"排错愈顺"。其效弥散：每时切换之境少，事解之速增，索诸多系之信息，所费之时而减。
省费甚巨。JetBrains之数据云，谓工作之时，有九至十四者，耗于工具之易。以五人组计，时值五十至百金，则年失之生产力，为三万六千至十一万二千金。减工具之蔓，四成（自十至六），虽不能尽绝情境之易，然省费年得一万四千至四万五千金。尤要者，减开发者纷扰多屏，致调试时漏察之虫。
工欲善其事，必先利其器。器愈少，则事愈易；器愈简，则用愈畅。调试之速，亦因之而增。此乃至简之理。非必待FinOps平台（FinOps平台）或开发者效率之器（开发者效率之器）也，此二者反为添器之举，非所宜也。
上次更新乃甲辰年七月廿四日