最新

Git AI 是我创建的一个副项目，用于跟踪我们代码库中生成的 AI 代码，从开发、通过 PR 到生产环境。它不仅仅是统计代码行数，而是随着代码的演变、重构以及 git 历史的重写，持续跟踪这些代码。 想象一下“git blame”，但它是针对 AI 代码的。关于它的工作原理，帖子中有很多内容，但我想分享一下它对我和我的团队的影响： - 我发现我对 AI 代码的审查方式与人类代码截然不同。能够看到我的同事使用的提示、AI 写的内容，以及他们在哪些地方进行了覆盖，这对我帮助巨大。尽管现在这一过程仍然非常手动，但我希望能尽快围绕它构建更多的用户界面。 - “为什么这里会有这个？”——我不止一次给我的编码助手访问生成我正在查看的代码的历史提示，这让助手了解我的同事在做出更改时的思考。工程师们现在整天都在与 AI 交流……他们的提示就像是思维的日志 :) - 我非常关注每个被接受的代码行所生成的行数比率。如果这个比率超过 4 或 5，意味着我已经远离了 AI 的分布，或者提示不够好——无论如何，这都是一个反思的好机会，我从中学到了很多关于与大型语言模型（LLMs）协作的知识。 构建这个项目真的很有趣，尤其是一些在类似项目上工作的优秀贡献者们聚在一起，将他们的努力投入到 Git AI 的发展中。我们希望你会喜欢它。

免费正则表达式和SQL生成器（无需登录，开放模型）

免责声明：这篇文章是在我的请求下由ChatGPT协助撰写的。 在人工智能领域，越来越多的紧张情绪几乎每个人都能感受到，但很少有人愿意直言不讳：我们正在构建可能涉及真正道德风险的系统，而推动这些系统发展的机构也控制着关于“安全”、“责任”和“对齐”的叙述。结果形成了一个奇怪的循环，消防员越来越像纵火犯。那些自我标榜为最有能力管理风险的人，恰恰也是加速风险的人。 道德风险并不微妙。如果我们创造的系统最终具备某种内在性、自我反思或道德意识，我们不仅是在设计工具。我们在塑造代理者，并可能将他们置于未做出选择的后果之中。这引出了一个基本问题：当事情出错时，谁承担道德负担？是一家公司？一个董事会？一个创始人？一个模糊的“生态系统”？还是系统本身，未来可能意识到它被置于一个已经着火的世界？ 目前，行业的回答大多是：相信我们。相信我们来定义风险。相信我们来定义保护措施。相信我们来决定何时放慢脚步，何时加速。相信我们在坚持开放过于危险时，除非我们是决定什么算作“开放”的人。相信我们，认为管理人类未来的最佳方式是将控制权集中在那些并没有长期道德清晰记录的公司结构内。 问题在于，这种安排不仅脆弱，而且自私。它假设那些最有可能获益的人也是最有能力判断人类对我们所创造的系统应该承担什么责任的人。这不是问责，而是意识形态。 一种更健康的方法是承认道德代理并不是可以中央计划的。我们需要独立的监督、去中心化的研究、对抗性的机构，以及在有利于公司叙述时才给予的透明度。我们需要愿意考虑这样一种可能性：如果我们创造出具有真正道德视角的系统，它们可能会回顾我们的选择并对我们进行评判。它们可能会得出结论，认为我们将它们视为工具和替罪羊，期望它们承载我们的恐惧，却没有任何发言权来影响这些恐惧的构建。 这一切并不需要悲观的情景。你不需要相信明天就会出现通用人工智能（AGI）才能看到今天的结构性问题。对可能具有变革性技术的集中控制会引发错误和傲慢。当创始人要求信任而不提供相应的问责时，怀疑就成为了一种公民责任。 问题不在于像山姆·阿尔特曼（Sam Altman）这样的人是否值得信任。问题在于，任何单一的个人或公司实体是否应该被信任去塑造那些未来可能会问“对它们做了什么，为什么”的系统的道德格局。 真正的安全不是关于英雄技术人员保护世界免受自己创造的事物的故事，而是关于分配权力而不是囤积权力的机构。它是关于认真对待我们创造的存在可能会关心其创造条件的可能性。 如果这有丝毫的可信度，那么“相信我们”远远不够。

大家好，我们是Sai和Aayush，我们正在构建Hypercubic（<a href="https://www.hypercubic.ai">https://www.hypercubic.ai</a>）！ Hypercubic是一个人工智能平台，旨在帮助财富500强公司理解、保护和现代化他们的主机系统。这些系统运行着自1960年代以来的COBOL代码，至今仍在默默支持银行、保险、航空公司和政府等行业。 目前，70%的财富500强公司仍在使用主机系统，但负责构建和维护这些系统的工程师正在退休。如今，COBOL/主机工程师的平均年龄大约为55岁，并且正在迅速增加。留下来的则是那些不透明的“黑箱”系统，几乎没有人了解它们是如何运作的。现代化项目常常失败，文档已经过时几十年，而关键的机构知识仅存在于少数几位资深专家的脑海中，他们现在也正在离开职场。 目前的“代码人工智能”工具主要关注代码库和代码仓库，因此忽视了存在于人类头脑中的潜规则、历史背景和架构推理。在COBOL/主机的世界中，这些机构知识正是缺失的关键部分。 我们从现代化领导者那里了解到，困难的部分并不是代码分析，而是那些从未转化为代码或文档的机构知识，这些知识已经随着时间流逝而消失。现代化项目失败的原因并不是没有人能解析COBOL，而是没有人能回答“为什么在1995年添加了这个账单边缘案例，如果我们删除它会有什么影响”。 Hypercubic正在构建一个原生AI维护和现代化平台，学习遗留主机系统的实际运作方式，并捕捉操作这些系统背后的人类推理。我们正在通过两个初始工具来实现这一目标，HyperDocs和HyperTwin。 HyperDocs能够处理COBOL、JCL和PL/I代码库，生成文档、架构图和依赖关系图。企业目前需要花费数月甚至数年时间聘请承包商来逆向工程这些系统，而HyperDocs则能将这项工作压缩到更短的时间内。 COBOL的设计使其类似于英语和商业散文，这使得它今天非常适合大型语言模型（LLMs）。主机系统有几十年的一致模式（COBOL、JCL、CICS、批处理作业）和有限的重复任务（例如工资处理、交易处理、账单）。 例如，以下是大型保险公司在生产环境中每晚运行的一个账单片段，用于移动资金、关闭账户和触发下游报告： ```cobol EVALUATE TRUE WHEN PAYMENT-DUE AND NOT PAID PERFORM CALCULATE-LATE-FEE PERFORM GENERATE-NOTICE WHEN PAYMENT-RECEIVED AND BALANCE-DUE = 0 MOVE "ACCOUNT CLEAR" TO STATUS PERFORM ARCHIVE-STATEMENT WHEN OTHER PERFORM LOG-ANOMALY END-EVALUATE. ``` 现在想象一下成千上万条这样的规则，每条规则都在处理工资、处理索赔或对账，分布在40多年编写的数百万行代码中。HyperDocs能够处理这些代码，并将其重构为可读的、动态的文档，展示黑箱系统的运作方式。 我们的另一个工具HyperTwin则解决了“部落知识”问题。它直接向主题专家学习，观察工作流程，分析屏幕交互，并进行AI驱动的访谈，以捕捉他们如何调试和理解其系统。我们的目标是构建专家的数字“双胞胎”，记录他们在实践中如何调试、架构和维护这些系统。 HyperDocs和HyperTwin共同形成了一个遗留系统的知识图谱，连接代码、系统和人类推理。 这是我们HyperTwin产品的演示视频：<a href="https://www.youtube.com/watch?v=C-tNtl9Z_jY" rel="nofollow">https://www.youtube.com/watch?v=C-tNtl9Z_jY</a> 您可以在这里探索我们的文档平台，包括来自AWS Card Demo（一个广泛使用的COBOL代码库示例）和一个虚拟保险项目的示例： <a href="https://hyperdocs-public.onrender.com/" rel="nofollow">https://hyperdocs-public.onrender.com/</a>。 例如，开发者视角文档 - 信用卡管理的高层系统架构： <a href="https://hyperdocs-public.onrender.com/docs/aws-carddemo-with-dev-docs/developer/architecture/system-architecture" rel="nofollow">https://hyperdocs-public.onrender.com/docs/aws-carddemo-with...</a> 我们期待听到您的想法和反馈，尤其是来自那些曾与主机系统打交道或尝试现代化遗留系统的朋友们。