最新

我们花了上个月的时间来建模软件预算，以找出为什么即使是资深团队，开发速度也常常感觉如此之慢。简而言之，原因似乎是结构性的：大约 80% 的工程时间花在了非差异化的基础设施（身份验证、管道、CRUD）上，而不是独特的业务逻辑上。 我们称之为“基础设施税”。我们分析了一份匿名的 240 万美元的工程支出，老实说，这个分解令人沮丧。只有大约 20% 的预算用于真正区分产品的特性。剩下的呢？身份验证流程、数据库配置、CI/CD 管道，以及第 50 次编写相同的用户模式。即使有了现代框架，感觉我们也一直在支付通行费，只是为了到达起跑线。 为了量化这一点，我们建立了一个理论模型（是的，我知道，模型不是现实，但请耐心听我说）。我们采用了标准的创业公司场景： - 5 名开发人员 - 总成本 50 万美元/年（保守输入） - 标准 SaaS 需求 我们将时间映射到“设置/样板”与“核心业务逻辑”。然后，我们模拟了一种“AI 原生”方法，其中 AI 处理大约 90% 的初始脚手架——不仅仅是编写函数，而是将堆栈连接在一起。 数学计算表明结构发生了逆转。在传统模型中，你看到的大约是 80/20 的比例（维护/基础设施与特性）。通过大量 AI 自动化处理样板，这个比例会向 30/70 转变。 对于一个 5 人的团队，该模型意味着每年可以节省大约 900 多个小时。但真正的指标不是节省的时间，而是机会成本。如果你发布 20 个特性而不是 12 个，价值差异是非线性的。这是找到产品市场契合点和耗尽资金之间的区别。 显然，这就是怀疑开始的地方（而且是正确的）。这里存在巨大的警告： - *维护负担：* 生成代码很容易创建，但调试可能是一场噩梦。如果 AI 吐出意大利面代码，你没有节省时间；你只是将痛苦推迟到维护阶段。 - *架构锁定：* 自动化设置通常意味着僵化的观点。如果你的应用程序不符合“标准 SaaS”模式，与生成的抽象作斗争可能比从头开始编写它的成本更高。 - *“黑盒子”风险：* 初级开发人员生成他们根本不理解的基础设施，这存在真正的危险，导致高级开发人员以后必须修补的安全漏洞。 我们正在使用这些模型来考虑内部资源分配，但我很好奇这是否符合你的现实情况。 - 80/20 的比例是否适用于你的堆栈，或者现代工具（Vercel/Supabase/等）是否已经为你解决了这个问题？ - “机会成本”是你实际在工程中跟踪的指标，还是只是 CFO 们谈论的事情？ - 对于那些使用 AI 进行脚手架的人：你是否在调试成本上为此付出了代价？ 我怀疑“基础设施税”是软件感觉昂贵的主要原因，但也许我低估了定制管道的价值。

开发了 Scrollie，一款用于长截图工作流程的 iOS 应用。 主要用途：将录屏（或截图序列）转换为一张长图，减少手动操作。 当前重点： * 设备端拼接 * 导出编辑（模糊/马赛克、文字、形状、水印） * 草稿自动保存 + 恢复 App Store： [https://apps.apple.com/app/scrollie/id6757146579](https://apps.apple.com/app/scrollie/id6757146579) 限时促销现已开始（约 48 小时）：终身解锁免费。 截止日期：2026 年 3 月 7 日 08:01 UTC 领取路径：设置 -> 升级到 Pro -> 终身（免费 / 0 美元） 如果现在以 0 美元领取，终身解锁将永久有效，之后不会自动收费。早鸟价格仅适用于错过此免费窗口的用户。

Hi HN， 我开发了 *CodeDrift*，一个 CLI 工具，用于检测由 Copilot、Cursor 和 ChatGPT 等 AI 编码助手经常引入的错误。 在过去的一年里，我注意到 AI 工具经常生成能够正确编译、通过 linting 检查，并且在代码审查中看起来合理的代码，但仍然包含一些细微的问题。 我经常看到的一些常见例子包括： * 未等待 Promise 的异步 `forEach` 循环 * 缺少授权检查（IDOR） * 幻觉依赖项（不存在的依赖项） * 泄露敏感信息的堆栈跟踪 * 未经验证就使用的请求数据 这些错误常常会逃过 ESLint、TypeScript 甚至人工审查员的眼睛，因为代码 <i>看起来</i> 是正确的。 CodeDrift 使用 TypeScript 编译器 API 解析代码，并运行一组检测器来查找这些模式。 例如： ``` async function syncProducts(items) { items.forEach(async (item) =&gt; { await updateStock(item.id); }); } ``` CodeDrift 输出： ``` CRITICAL: async forEach does not await promises Fix: use Promise.all or a for...of loop ``` 它检测到的另一个例子： ``` Database query using user-supplied ID without authorization check → potential IDOR vulnerability ``` 其目标不是取代 ESLint 或 TypeScript 等工具，也不是取代 Snyk 等安全扫描器。 它旨在作为使用 AI 助手生成的代码的安全层。 该工具在本地运行，不需要云访问，可以通过以下方式试用： ``` npx codedrift ``` 我很乐意收到正在生产中使用 AI 编码工具的开发者的反馈。

我构建 Anaya 是为了解决我一直看到的一个问题： 印度的《数字个人数据保护法》（DPDP 法案）现已生效（规则已于 2025 年 11 月公布，截止日期为 2027 年 5 月），但合规性是一个代码问题，不仅仅是一个法律清单。 之前没有为此提供任何工具。 我在 Saleor（开源 Django 电子商务，107 个模型）上运行了它：在 82 秒内发现了 4 项违规行为——没有同意机制，70 个 PII 字段以明文形式存储，没有任何 PII 模型的 DELETE 端点。 ```bash pip install anaya && anaya compliance . ``` 代码：[https://github.com/sandip-pathe/anaya-scan](https://github.com/sandip-pathe/anaya-scan) 欢迎讨论 AST 解析方法或 DPDP 部分分析器设计。

大家好，HN！我们是 X25 的校友，创建了 Parsewise，用 AI 智能体分析大型文档集。<p>与只针对单个 PDF 提问不同，我们的智能体可以在一次运行中提取、交叉引用并推理数千份文档。<p>我们最初是为保险和财务尽职调查流程构建的，这些流程中团队需要审查大量的文档包。<p>很好奇 HN 社区的看法！<p>欢迎查看我们的公开演示： demo.parsewise.ai/insurance-claims-triage demo.parsewise.ai/reinsurance-recovery-optimization demo.parsewise.ai/investment-diligence demo.parsewise.ai/mortgage-underwriting