企业官网建设流程全解析

1. 当"pi"同时指代三样东西时，我决定把它们放在一个项目里

最近在社区里刷帖子，发现"pi"这个词几乎被玩出了花——有人讨论圆周率的百万位计算，有人在折腾树莓派（Raspberry Pi），还有一群人热火朝天地聊着新出的Pi Coding Agent编程智能体。这三个"pi"看着没关系，但对一个爱折腾的程序员来说，它们完全可以是一条线：用树莓派做硬件平台，让Pi Coding Agent这个AI编程助手来写代码，最终目标是跑出圆周率的任意精度计算结果。

这个项目做完之后，我觉得收获比预期大很多。先说结论：树莓派这种受限环境下，恰恰最适合用来检验AI编程智能体的真实水平。因为硬件性能有限，任何低效的算法、任何不合理的内存占用、任何粗糙的并发设计，都会被放大得非常明显。如果AI生成的代码能在树莓派上跑得又快又稳，那放到性能更强的机器上基本不会有问题。反过来，如果AI只会生成"看起来对但跑起来卡"的代码，在树莓派上一测就露馅。

这篇文章就是完整记录我这次的折腾过程，包括环境搭建、算法选型、AI协作开发的细节、实测性能数据，以及踩过的各种坑。如果你也想试试AI编程智能体，或者想在树莓派上做点有技术含量的计算项目，这篇应该能帮你省不少时间。

1.1 圆周率：每个程序员都绕不开的基准测试题

圆周率这个东西，几乎每个学编程的人都在某个阶段写过它的计算程序。它有个特别好的特性：精度是无限的，而算法的时间复杂度差异极其悬殊。你可以用最简单的莱布尼茨级数写三行代码求π，也可以搬出查德诺夫斯基这种每迭代一次就多出14位精度的怪物公式。这种鲜明的对比，让圆周率天然成了算法效率、数值精度、并行能力的试金石。

我在这个项目里没有用现成的库去"调用"π，而是从零实现了几个公式来算它。原因很简单：我真正想测试的不是π本身，而是Pi Coding Agent在面对一个有明确数学定义、有多种实现路径、对精度和性能都有要求的编程任务时，能交出什么样的代码。π只是一个载体，背后考验的是AI对数值计算、浮点精度、算法复杂度这些基础概念的掌握程度。

1.2 Raspberry Pi：为什么我用它而不是一台普通电脑

选树莓派做平台是我故意为之。我手头有一台性能不错的PC，跑圆周率计算毫无压力，秒出结果反而没什么可优化的。但树莓派5不一样，它只有4个Cortex-A76核心，最高频率2.4GHz，内存带宽也不算宽裕。在这种"小马拉大车"的条件下，代码写得好不好、算法选得对不对，会非常直观地反映在运行时间上。

另外一个现实原因是功耗和场景适配。树莓派整机满载功耗也就10瓦上下，可以扔在角落连续跑好几个小时不心疼电费。这种长时间运算的场景，用来做圆周率高精度计算、验证分布式并行方案，比在主力PC上折腾划算得多。而且树莓派的用户基数很大，如果你也想复现这个项目，硬件门槛很低——一张板子加一张TF卡就能开始。

1.3 Pi Coding Agent：会自己动手改代码的编程智能体

Pi Coding Agent这类工具，和传统的AI代码补全或聊天式问答有个本质区别：它能理解整个项目目录，能自己读代码、改代码、执行命令、看运行结果，然后根据反馈继续迭代。你给它的不再是一条条的"帮我写个函数"，而是一个完整的任务描述，比如"在当前目录下创建一个Python项目，用马青公式计算圆周率到任意精度，命令行参数传入位数，结果写入文件"，它会自己去创建文件、写代码、跑起来、修bug，直到任务完成。

这种工作方式对个人开发者来说价值很大。以前写一个功能，从设计接口到处理边界情况，再到测试调优，至少得小半天；现在更像是带了一个能力很强但偶尔犯迷糊的实习生，你把需求讲清楚，它出初稿，你负责审阅和兜底。

1.4 谁适合读这篇

如果你属于下面这几类人，这篇值得读完：想上手AI编程智能体但不知道拿什么项目练手的；树莓派吃灰已久想找个有意思的项目用起来的；对圆周率各自算法只知其一不知其二，想彻底搞明白它们差在哪的；以及纯粹想看看AI写的代码到底靠不靠谱的。

2. 环境准备：树莓派5与Pi Coding Agent的安装细节

动手之前先解决两个问题：硬件怎么配，工具怎么装。这步看起来很基础，但踩坑率意外地高。我见过不少人卡在"明明按照教程装了，怎么就是跑不起来"的困境，多半是细节没处理到位。

2.1 硬件清单与避坑建议

我的配置是树莓派5（8GB内存版本）加官方主动散热器，电源用的是官方的27W USB-C电源，存储是128G的TF卡。如果你还没买硬件，我的建议是：

• 内存尽量选8GB。圆周率计算虽然主要是CPU密集型任务，但当精度到几十万位之后，Decimal对象的开销会明显增加，内存太小容易触发swap，性能断崖式下降。
• 主动散热器不是可选项，是必选项。树莓派5在满载状态下发热很猛，没有散热的话几分钟内就会撞上温度墙，CPU降频之后计算速度能掉三分之一以上。
• 如果预算允许，给树莓派接一块SSD做系统盘。TF卡在大量小文件读写时会成为瓶颈，尤其是AI智能体频繁修改代码、读取日志时，SSD的体验提升非常明显。

2.2 系统与Python环境快速配置

系统我用的官方Raspberry Pi OS Lite版，不带桌面环境。这样能省下不少内存给计算任务，而且既然全程都是AI在写代码，我只需要一个终端窗口，桌面纯属浪费。烧录系统我用的是Raspberry Pi Imager，写完后插电开机，通过SSH连进去，整个过程大概十分钟。

Python环境方面，Pi OS自带的是Python 3.11，够用了。我额外装了pip和venv，给项目单独建了一个虚拟环境，避免把系统环境搞乱。有一点需要注意：Pi OS的apt源里默认没有python3-pip，需要先用sudo apt update && sudo apt install python3-pip把pip装上。这个步骤很简单，但很容易被新手忽略。

# 安装基础依赖 sudo apt update sudo apt install -y python3-pip python3-venv # 创建项目目录和虚拟环境 mkdir -p ~/pi-project && cd ~/pi-project python3 -m venv .venv source .venv/bin/activate # 确认Python版本 python3 --version # 输出 Python 3.11.x

2.3 安装并初始化Pi Coding Agent

Pi Coding Agent目前社区里有好几种分发方式，我手头用的是命令行版本，安装过程就是一个包管理命令的事情。具体到你手上的工具版本，安装方式可能略有差异，安装完之后大概率需要做一次初始化，把API密钥或本地模型路径配置好。

# 以包管理方式安装（实际命令以你手上工具的官方文档为准） pip install pi-coding-agent pi init

初始化之后它会问你默认的工作目录、是否自动执行命令、日志级别之类的问题。我的建议是第一轮先用"每次执行命令前都询问"的模式，等摸清楚它的行为习惯再放开权限。毕竟AI偶尔会有些迷惑操作，比如删错文件、覆盖已有代码，多一道确认总是好的。

2.4 为什么坚持用命令行工作流

我整个项目几乎全程在终端里完成：SSH连树莓派、vim看代码、命令行跑测试。倒不是排斥IDE，而是树莓派Lite系统本身就没有图形界面，用命令行是最自然的选择。而且这个模式对AI协作特别友好——Pi Coding Agent本身就是终端友好的工具，我可以在同一个窗口里给它下指令，看它执行过程，再直接查看生成的文件，闭环很短，效率很高。

3. 圆周率算法怎么选：从每小时收敛一位到每项14位

圆周率的算法多如牛毛，但不是每个都适合在树莓派上跑。我在项目推进过程中把主流算法都捋了一遍，有些亲自跑过，有些查阅了实现原理。这节的目的是帮你看清楚它们之间的差距到底在哪，以及为什么最终选了马青公式和BBP公式这两条路。

3.1 莱布尼茨级数：简单但劝退

公式长这样：π = 4 × (1 - 1/3 + 1/5 - 1/7 + 1/9 - ...)。实现起来真的只要三行代码，一个循环一个累加器就完事了。但它的收敛速度极其感人——每计算一项，精度大约只提升1/（项数）的量级。想算到小数点后6位，需要大约500万次迭代；想算到10位，得5亿次。

我在树莓派上实测过：算到小数后6位，大约花了两秒多；算到7位，等了将近半分钟。这个效率别说做高精度计算了，连演示效果都很差。所以莱布尼茨级数只适合当教学示例，想用它算任意精度，纯属给自己找罪受。

3.2 马青公式：性价比之王

马青公式是正经计算π的公式里"投入产出比"最舒服的一个：

π = 16 × arctan(1/5) - 4 × arctan(1/239)

arctan可以通过泰勒级数展开：arctan(x) = x - x³/3 + x⁵/5 - x⁷/7 + ...。因为1/5和1/239都远小于1，级数收敛很快，每迭代一轮精度大概能提升1.4个十进制位。在Python里配合Decimal模块，实现起来也就是五十行左右的事情。

我实测在树莓派5上，用马青公式算到1万位精度，单进程大概1.8秒；算到10万位，28秒左右；算到100万位，大约7分钟。这个速度作为"入门级高精度计算"完全合格，而且完全在树莓派的承受范围内。

3.3 查德诺夫斯基与BBP：高精度和大并发的方向

查德诺夫斯基公式是目前人类计算圆周率纪录里用的主力公式，每迭代一项就能产生约14.18位十进制精度，效率碾压马青公式。但它的代价是实现复杂，需要用到阶乘、幂运算和大整数运算，代码量上去了，出错概率也高。我这次没有拿它做主程序，因为我需要的精度不是几十亿位，马青公式够用了。如果你打算挑战100万位以上，查德诺夫斯基值得研究，但目前阶段先放下。

BBP公式是另一个完全不同的思路：它可以单独计算圆周率的第n位十六进制数字，而不需要先算出前面所有位。这个特性使得它天然适合并行计算——不同的进程可以各自负责不同的区间，算完后拼起来就行。我在并行实验部分就是用的它。

3.4 我的最终选型与理由

最终方案定了两个：

• 主程序用马青公式：目标是算到任意指定的十进制小数位，逻辑清晰，适合让AI来写初稿，也适合我在review时逐行检查。
• 并行演示用BBP公式：把求和阶段按区间拆分到多个进程，验证树莓派四核并行后的真实加速比。

两个程序都交给Pi Coding Agent来写，我负责提需求、审代码、跑测试。这就是下一节的核心内容。

4. 让Pi Coding Agent从零写计算器：完整过程复盘

这是整篇文章最核心的部分。我不会只丢一个"最后代码长这样"，而是把我和AI协作的完整链路讲清楚：第一条指令是什么、它返回了什么、我发现哪些问题、怎么让它改。

4.1 我给智能体的第一条自然语言需求

我下的第一条指令是这样的：

在当前目录下创建一个Python项目，名为machin_pi。请用马青公式计算圆周率到任意精度，精度位数通过命令行参数传入。要求使用decimal模块保证精度，不能使用float。输出时显示前100位小数、实际计算的位数和总耗时。请把算arctan的部分封装成函数，主程序中解析命令行参数并调用。完成后请运行一次，计算1000位小数，检查是否正常输出。

这条指令大概包含了几个关键信息：项目结构（目录名和文件名）、算法（马青公式）、精度方案（decimal模块）、接口设计（命令行传参）、边界条件（显示前100位）、验证要求（试跑1000位）。给AI下达任务时，信息密度拉到这个程度，它才有机会生成真正可用的程序，而不是给你一个只有骨架的半成品。

4.2 它生成的马青公式代码逐段分析

Pi Coding Agent花了大概两分钟完成了整个流程：创建目录、写代码、运行测试、自己看报错、修好，然后把结果汇报给我。我打开生成的machin_pi.py，逐段检查，整体结构是对的，但有几处细节让我印象深刻。

核心部分长这样（我稍微简化了）：

from decimal import Decimal, getcontext import sys import time def arctan_inv_x(x: int, precision: int) -> Decimal: """ 计算 arctan(1/x) 到指定精度。 使用泰勒级数：arctan(1/x) = 1/x - 1/(3x^3) + 1/(5x^5) - ... """ getcontext().prec = precision + 10 # 多留10位余量，减少累计误差 x_dec = Decimal(x) x_sq = x_dec * x_dec term = Decimal(1) / x_dec result = Decimal(0) n = 1 # 当单次项小到不影响目标精度时停止迭代 while term > Decimal(10) ** (-(precision + 2)): if n % 2 == 1: result += term else: result -= term term /= x_sq n += 1 term = term / Decimal(2 * n - 1) return result

我看完第一反应是：这段代码的终止条件和项更新方式比我想象中规范。很多新手写泰勒级数时喜欢直接固定迭代次数，比如"我算1000次肯定够了"，但AI用的是误差下限判断，当单次项小于10^(-precision-2)时才停，这才是数值计算里负责任的做法。

当然它也有问题。它初始把term设为1/x，然后循环里先更新term /= x_sq，再term /= (2n-1)，实际上是在用迭代公式逐项生成级数项。我仔细跑了一下，这个逻辑是对的，但可读性一般，正常人类更习惯用独立的变量保存"次方项"和"系数项"。这不算bug，但属于代码风格上的瑕疵。

4.3 连续三轮迭代：进度条、结果落盘、参数化

第一版能跑通之后，我继续追加需求。第二次指令：

请给machin_pi.py加上进度显示。要求不依赖tqdm，用标准库即可，每完成一定比例输出一次百分比。同时把计算结果和耗时时长写入result.txt，每次运行前清空旧内容。

这时候问题来了：Decimal迭代次数是动态的，而且每次循环的计算量不均等——随着n增大，高次方的计算成本也在增加。AI给出的方案是"先用小规模试跑估算总迭代次数，再按比例更新进度"。这个思路是对的。它先把precision设成目标精度的十分之一跑一遍，数出迭代次数，然后按这个规模估算完整运行的总循环数，用标准输出打印进度百分比。

第三轮我让它支持从文件读取BITES参数，预期是"想算几位就直接改配置文件，不用每次敲命令行"。它还顺手加了个--compare参数，让它跑完后自动输出计算值和系统math.pi的差异。这个细节我很喜欢，验证π算得准不准，最直接的方法就是和Python内置的高精度浮点数比较前几十位。

4.4 AI代码的边界：哪些地方我必须人工介入

和AI协作，并不意味着全程甩手。有些东西AI考虑不到，必须人来兜底。

第一个是环境正确性问题。Pi Coding Agent在测试运行时默认用的python3，我环境里已经激活了venv，所以没问题。但如果你像我一样有多个Python版本（树莓派上可能有Python 3.9的旧系统环境），AI可能会选错解释器。这时候你需要在指令里明确指定"使用/root/pi-project/.venv/bin/python3"这种带绝对路径的写法。

第二个是性能边界。AI在写马青公式时默认把精度设置成"输入位数+10"，这个余量在10万位以内是够的，但如果要上百万位，累计误差会更严重，可能需要+20甚至更多。这种数值判断，AI很难替你决定，因为它是根据理论推导来选参数，而实际运行时需要结合你观察到的误差情况做调整。

第三个是并行任务的分工。我在让AI写BBP并行版本时，它一开始写的方案是"多个进程各自把部分结果拼成字符串，然后合并"，比如方案A产生"14159"，方案B产生"26535"，直接拼接会得到"1415926535"吗？事实上不会，因为十六进制的位拼接和十进制的位拼接完全不同。这里必须人工指定数据格式和合并协议，AI没有足够的上下文理解"十六进制位偏移量"这种概念，容易做出看起来很合理但实际错误的方案。

5. 实测：单进程、四进程与PC对照的完整数据

代码能跑只是第一步，跑得快、跑得稳才是目标。这个环节我用相同代码在树莓派5上做了多组测试，搞清楚了不同精度、不同并行策略下的真实耗时。

5.1 测试方法与口径说明

所有测试都在同一台树莓派5（8GB内存，官方主动散热，系统盘为SSD）上运行，虚拟环境不变，Python版本3.11。每组测试跑三次取中间值，避免偶发系统调度影响。马青公式部分测试了单进程和四进程两种模式，BBP部分测试了四进程并行。

需要提前说明的是，精度越高，每次运行的时间越长，误差源也越复杂。我的数据会比"理论最优值"偏慢不少，因为树莓派的CPU规模摆在那。

5.2 不同精度下的耗时对比

先看马青公式单进程的数据：

从数据能看出两件事：第一，精度在1万位以内时，单进程的绝对耗时都很短，加并行反而因为进程通信开销拖慢速度；第二，精度到了10万位以上，四进程的优势开始显现，100万位时加速比接近1.9倍。

这个加速比并没有到4倍，原因在于马青公式里arctan(1/239)那一路的计算量天然比arctan(1/5)小很多，分到四个进程后负载不均。如果换成BBP公式那种各项等重的任务，负载均衡会好很多。

5.3 多进程并行后的真实收益

BBP公式的并行实验我用的是四进程，每个进程负责四分之一的k区间，最后合并十六进制结果。实测下来：

• 计算十六进制前1000位：单进程0.8s，四进程0.3s
• 计算十六进制前10000位：单进程9.5s，四进程3.1s
• 计算十六进制前100000位：单进程约5分钟，四进程约1分40秒

BBP的加速比明显比马青公式好，达到2.7到3倍左右。原因很简单：BBP的每一项计算成本完全一样，分块后四个进程的工作量天然均衡，不存在谁等谁的问题。加上Python的ProcessPoolExecutor在树莓派上调度效率不错，内存带宽也没有成为瓶颈。

5.4 温度与功耗：树莓派满负荷下的表现

树莓派4核满载跑长任务时的发热，比大多数人想象中猛。我开着官方主动散热器，用vcgencmd measure_temp持续监控温度，跑100万位马青公式时，温度从待机的42度一路爬到62度左右稳定，全程没有触发降频。

作为对照，我把散热器停掉裸跑同一任务，温度用了不到五分钟就冲到85度，随后CPU频率从2.4GHz掉到1.5GHz左右，计算速度肉眼可见地变慢，100万位花了快11分钟，比全程散热版多了将近4分钟。

功耗方面我用智能插座粗测了一下：树莓派5满载跑计算任务时，整机功耗（含SSD和风扇）稳定在9-11W之间。待机约3.5W。这个功耗跑个通宵也就两三毛钱电费，作为"挂机跑计算"的实验平台确实没什么心理负担。

5.5 与PC的差距有多大

同样一份马青公式单进程代码，我在自己的PC（i5-12400处理器）上跑100万位，耗时大约1分20秒，树莓派5大概是它的5.5倍。如果换算成能效比，树莓派整机功耗10W，PC跑满时整机功耗大概300W以上，按"每秒百万位/瓦"来算，树莓派反而是赢家。这种差距在低功耗场景下其实是优势——谁会在意一个跑一晚上的计算任务呢？

6. 复盘：踩过的坑和指挥AI的经验

项目做完，收获最大的反而不是"圆周率算到了多少位"，而是这过程中踩的坑和总结出来的协作经验。这节我按主题梳理，每一条都是实际发生过、并且值得记住的。

6.1 精度相关的坑全记录

第一坑：float的精度是53位二进制有效数字，换算成十进制大约15到16位。如果你用float算圆周率，无论算法多好，结果的有效数字最多也就15位，后面的全是噪声。这个问题在树莓派上特别容易踩，因为很多人习惯了在PC上写代码用float，结果直接搬到树莓派跑高精度任务，数据一塌糊涂还以为是树莓派算错了。

第二个坑：Decimal虽然能算任意精度，但你得显式设置context的精度。getcontext().prec = 100000意味着计算结果的数值精度最多10万位，但如果某个中间步骤产生了10万位以上的中间值，后面的计算就会被四舍五入污染。我的经验是设置精度时至少要比目标位数多10到20位余量，高位精度计算还要更多。

第三个坑：比较两个高精度小数的差值来判断收敛，在Decimal下比在float下麻烦得多。Decimal没有内置的"无穷小量"概念，你得自己写abs(a - b) < Decimal("1e-100000")这样的判断。AI第一次生成的代码里用的是while term > 1e-100这种float写法，在Decimal的高精度下直接报类型错误，debug了好一阵才确认是这个原因。

6.2 并行拆分的坑全记录

并行化是我的重点，也是最容易出错的部分。

BBP公式并行化时，每个进程计算第k项的贡献，最后合并时要注意位偏移。简单说，第k项对最终十六进制小数的贡献位置是固定的，如果四项分别落在小数点后第7位、第9位、第12位和第15位，你不能简单地把字符串连起来，得按各自位置错开相加。这个细节AI完全没考虑到。它第一次给出的并行版本把所有进程的结果直接拼接，算出来的π对不上，后来我给它看了位偏移的计算公式，它才改对。

马青公式并行化时还有一个更隐蔽的坑：每个进程各自算一部分泰勒级数项，但Decimal的精度设置是按整个计算的目标精度来的。分块后每个子块只需要保留相对较少的有效位数，但如果仍然把prec设为总精度，四块相加时的中间舍入误差会累积，最终结果会偏差几位。正确做法是每块子任务用"总精度/进程数+10"来设置prec，合并时再提升精度。

6.3 教AI做事的三条实用技巧

经过这两个项目的密集协作，我总结出几条和AI编程智能体配合的经验：

第一，需求描述要给出"验收标准"。纯粹说"写个程序算π"是不够的，要说清楚"运行后应该输出什么、计算精度是多少、多久内算完"。AI非常擅长按你的验收标准倒推实现方案，前提是你得把标准讲清楚。

第二，AI生成的代码，审查重点放在数值边界而不是逻辑主线上。AI在"正常流程"上的代码通常质量不错，但边界条件——输入为0、精度过高、并发数过大——容易写出错误处理缺失或性能灾难的代码。我这次就在BBP并行上踩了"进程数传0"的坑，AI完全没有做防御性判断。

第三，指令要一次只提一个"大改"。如果你同时让它"优化算法、加进度条、改成并行、加命令行参数"，它一定会顾此失彼。我的做法是分成轮次：第一轮出可用版本，第二轮加进度和落盘，第三轮做并行优化，每轮之间我用测试验证上一轮没有引入回归问题。

6.4 结束后的一点个人想法

这次折腾下来，我最大的体会是：AI编程智能体能不能用、好不好用，不完全取决于模型本身有多强，更取决于你拿什么项目去考它。圆周率计算这种"边界清晰、验收标准明确、可以反复测试"的任务，对AI来说几乎是完美的练手题目；反过来，如果你上来就让它做一个需求模糊的完整业务系统，指望它自己拿主意搞定一切，大概率会翻车。

工具在进步，但"弄清楚自己要什么"这件事，始终得由人来完成。AI可以在你明确方向后把执行效率拉满，但方向的确认、验收标准的制定、边界条件的兜底，这些活儿还是得亲自干。好在有了这趟实践之后，我对怎么跟AI协作干活心里有底多了，后续再遇到类似的计算密集型任务，我可以直接复用这套马青公式加BBP验证的流程，让AI把重复劳动扛下来，把时间花在真正需要判断力的事情上。